Skip to main content

​
Per-assignment behaviour

When you assign a keyword to a document type, you also control how it behaves on that type’s indexing form. The same keyword type can behave differently on different document types — required on one, hidden on another — because behaviour is set on the assignment, not on the keyword type itself. You set these on each keyword in the assignment editor under Admin settings → Keywords → Keyword assignments. To change one setting across many keywords at once, use bulk edit.
Keyword assignment editor showing each assigned keyword's required, hidden, read-only, unique, required-for-retrieval, and default value controls

​
The behaviour flags

Read-only and hidden are different: a read-only keyword is visible but locked, a hidden keyword is not shown at all. Combine default value with read-only to stamp a fixed value users can see but not change.
Be deliberate with required and unique on document types that already hold documents. Existing documents that don’t satisfy a newly required or unique keyword can cause validation to fail the next time they’re edited.

​
Configure group members on each document type

Expand an assigned keyword group in Keyword assignments to edit its members’ required, hidden, read-only, unique, retrieval, and default-value settings. These choices apply to that document type, so the same group can behave differently on another type. You do not need to duplicate a member as a standalone assignment; duplicate representation is rejected.

​
Group system-managed keywords in personal pickers

Under Keyword behavior, use System-use keywords to tag fields that automation fills, then save. In personal Hidden keywords and Upload behavior settings, tagged fields appear under System keywords, after the other keyword headings. This is a picker organisation setting. It does not hide values, make a field read-only, change access, or change how values are stored. Tagged fields remain selectable and can be removed from an existing personal selection. Use assignment flags or access rules for enforcement.

​
Conditional keyword rules

Beyond per-keyword flags, you can define conditional rules that change keyword behaviour based on other values — for example, show a keyword only when another keyword has a particular value, or set a default conditionally. Manage these under Admin settings → Keywords → Keyword behavior. Conditional rules are scoped per document type and are evaluated live on the indexing form as users enter values. They’re the tool to reach for when a static required or hidden flag isn’t enough and the behaviour needs to depend on context. Conditional rules act on the indexing form while users enter values. To calculate a keyword’s value from other keywords every time a document is saved — by users, workflows, scripts or integrations alike — use a calculated keyword, such as a deletion date calculated from a termination date.
The Keyword behavior settings page showing global keyword behaviour options and keyword conditional rules

​
Reveal fields progressively

Use IsEmpty to react when the trigger keyword has no non-blank value, and HasValue when it has one. These operators need no comparison value. For example, hide Department while Organisation is empty, then hide Team while Department is empty. Clearing Organisation should collapse both dependent fields. Rule-hidden fields are excluded from the indexing payload, so test clearing an upstream value as well as entering one. Avoid a chain that hides information the user must review before saving.

Calculated keywords

Calculate a keyword from other keywords of the same document every time a document is saved.

Document access rights

Grant user groups the privileges to view, create, modify, delete, and otherwise work with documents of each document type.

Keyword assignment models

Add the keywords whose behaviour you’re configuring, as standalone fields or groups.

Document types

The document types these keyword behaviours apply to.