Skip to main content

​
Prerequisites

Open Admin settings → Keywords → Security keywords. Reading rules requires both keyword-configuration.view and iam.user-groups.view; maintaining rules requires both corresponding manage permissions. The current security-keyword feature must be available in the environment. If the screen reports that it is disabled, do not assume rules entered here are active. Security keywords add record-level restrictions to document-type rights. They do not grant access to a document type that a user otherwise cannot access.

​
Understand what a match means

A rule is a conditional restriction, not an allowlist. When its condition does not match, that rule imposes no restriction. A rule matching Department = Finance does not, by itself, deny access to other departments.
For an applicable keyword type, the allowed operations of all matching rules from the user’s groups are combined. A second matching rule can therefore allow an operation restricted by the first. Restrictions from different keyword types are then combined: an operation must survive each applicable keyword type’s restrictions. For example, a rule matching Classification = Confidential with only View selected restricts matching records to viewing at this layer. It does not remove the need for document-type view access, and it does not restrict records whose classification does not match.

​
Create a rule

  1. Choose Add Rule and select the user group and keyword type.
  2. Choose a supported operator and values. Operators offered depend on the keyword’s data type; ranges require appropriate numeric or date values.
  3. Select specific document types, or deliberately choose Apply to all document types.
  4. Select Allowed Operations, review Enabled, and save.
The group and keyword type cannot be changed after creation. Create a replacement rule if those need to change. The editor also offers dynamic placeholders; use its supported placeholder picker rather than inventing placeholder names.

A rule combines a group, keyword condition, document scope, and allowed operations. Complete all required selections before saving.

​
Validate effective access

Use representative accounts and documents in a test environment. Include a matching value, a nonmatching value, missing metadata, multiple values, and a person belonging to more than one relevant group. Check search visibility and direct document access, plus each operation the policy should restrict. Do not validate only with an unrestricted administrator. An additional group or matching rule can change the effective result. Check the feature’s enabled state and document-type scope before concluding that a saved rule is enforced.

​
Maintain and investigate

Filter the rule list by group or keyword type. Use Enable Selected or Disable Selected for deliberate batch changes, then inspect the results and Audit History. The page also provides Clear Cache for rule-cache troubleshooting; verify the saved rule and the account’s group membership first. Removing or disabling a restriction can broaden access. Re-run the representative access checks after changing a rule, including AI search when your environment uses it. AI indexing must preserve the security metadata needed for filtering; see AI search index administration.

Mass value editing

Preview and replace a stored alphanumeric keyword value across a selected document scope, then monitor the background job.