Best practices for ServiceNow access & audiences

A practical guide for configuring who can see your ServiceNow knowledge articles once they sync into Leena AI Knowledge Management (KM). Set access up the recommended way and the KM audience will match exactly what a user would see in the ServiceNow portal.

How access works, in one line

A user can read an article in KM only if they could read it in the ServiceNow portal. They must satisfy the Knowledge Base's read rules and the article's read rules and any role required on the article.

Each layer is a filter that can only narrow the audience, never widen it. Anyone explicitly denied is then removed:

Who can read = (KB "Can Read") filtered by (Article "Can Read") filtered by (Article Role), minus anyone in "Cannot Read", plus the custodians who always keep access.

Before anything else: is permission sync on?

Permission syncing is controlled by a master setting on the Leena AI side.

• On (recommended): audiences are calculated and applied as described here.
• Off: no permissions are synced, and every article becomes visible to all KM users. Use this only if the Knowledge Base is meant to be fully public.

Set the baseline: Knowledge Base–level access

This is the primary and recommended control. It sets the default audience for every article in the Knowledge Base.

In ServiceNow:

1. Go to Knowledge → Knowledge Bases and open your KB.

2. In the Can Read field, add one or more User Criteria.

   

3. Optionally use Cannot Read to explicitly exclude people.

4. Can Contribute / Cannot Contribute work the same way for the contributor audience.

If a KB has no Can Read criteria at all, the baseline is treated as everyone (then still narrowed by any article-level rules). To lock down no-criteria articles instead, see ServiceNow settings that change the outcome.

Narrow it per article (optional)

Use this when a specific article needs a tighter audience than its Knowledge Base.

In ServiceNow:

1. Open the article.
2. Set its Can Read field to one or more User Criteria.
3. Optionally set Cannot Read to exclude specific people.

Two things to remember:

• Article-level access can only remove people from the KB baseline — it can never add someone the KB didn't already allow. So align the KB baseline too; don't place a sensitive article in an otherwise-open KB and expect one article rule to protect it.
• Article-level Can Read only takes effect if the ServiceNow property glide.knowman.apply_article_read_criteria is on. If it's off, only KB-level rules apply.

What a User Criteria can be built from

User Criteria are the building blocks of access. A single User Criteria can grant access by any combination of the dimensions below (members of every filled-in dimension are combined):

Restricting by role (optional extra gate)

ServiceNow lets an article additionally require a role to read it. On the article, set the Roles field to one or more role names. Leave it empty (or use public) to mean "no role restriction."

How it behaves:

• The role is an extra filter on top of the User Criteria — only users who both satisfy the criteria and hold the role keep access. A role narrows the audience, never widens it.
• public means "everyone" / no restriction. Never use public as a placeholder when you actually want to restrict.
• If a role has no users assigned (e.g. a typo or an empty role), the article collapses to custodians only. Keep the gating role's membership accurate and granted to exactly the people who should see the content.
• This gate is enabled per account on request. If you rely on article roles, tell your Leena AI contact so it can be switched on. When it isn't enabled, the Roles field is ignored.

Who always keeps access (custodians)

These users always retain access to an article regardless of any criteria or role — this is automatic and needs no configuration:

• The article Author
• The Knowledge Base Owner
• The Knowledge Base Managers
• All users with the admin role

Don't rely on criteria or roles to exclude these people — they'll always see the article. Control who the custodians are by setting the Owner and Managers fields on the Knowledge Base record.

ServiceNow settings that change the outcome

Two ServiceNow instance properties (under Knowledge Management settings) are read live and honored, so KM matches the portal. Set them to match the access posture you want:

How changes take effect

• Article content changes are picked up automatically on the next sync.
• Permission changes (User Criteria, group membership, KB criteria, roles) don't change an article's last-modified date in ServiceNow, so they're detected separately and recomputed automatically. Allow one sync cycle for permission edits to appear in KM.
• A short cache (up to ~30 minutes) on directory lookups means very recent group-membership or criteria edits may take one additional sync to settle.

For exactly how each change type propagates, see How changes propagate on the integration page.

Best-practice do's

1. Make User Criteria your primary control. Prefer KB and article Can Read / Cannot Read over dropping a bare role on an article — criteria are richer and always evaluated.
2. Reference roles/groups inside a User Criteria where you can. This keeps a single, predictable access definition rather than splitting intent across a criteria and a separate article role.
3. Restrict at the right level. Set the KB baseline first, then narrow specific articles — and keep the two aligned.
4. Use field-based criteria, never scripted ones.
5. Set the two ServiceNow properties deliberately so your intended default (open vs locked-down, article-level rules on/off) is what actually happens.
6. Never use public as a placeholder for a restriction.
7. Keep role and group membership accurate and current; review periodically, since stale or over-broad membership directly inflates who can see content.
8. Use Cannot Read carefully — it subtracts from Can Read, so double-check you aren't removing intended readers.
9. Set the KB Owner and Managers so the right custodians retain access.
10. For groups, rely on active membership, and remember subgroup members are inherited up to the parent.

Setup checklist

For a Knowledge Base that should be access-controlled:

• ☐ Confirm with Leena AI that permission sync is enabled for your account.
• ☐ Set Can Read User Criteria on the Knowledge Base (the baseline).
• ☐ Use field-based User Criteria (User / Group / Role / Company / Location / Department), not scripted / Advanced criteria.
• ☐ For tighter per-article control, set Can Read on the article and ensure glide.knowman.apply_article_read_criteria is ON.
• ☐ If you gate articles by Role, ask Leena AI to enable the article-roles feature for your account.
• ☐ Set the KB Owner and Managers so custodians retain access.
• ☐ For groups, rely on active membership; remember subgroup members are inherited to the parent.