Manage access through user criteria and ownership groups

alex_chung · 47m ago

As people have been cleaning up their knowledge management to enable AI, I've been getting questions about knowledge permissions, such as "Why can't this person check out an article unless they're a knowledge admin?" They don't need to be.

Checking out an article needs contribute permission. In Knowledge Management v3, you control that permission with user criteria or with ownership groups, rather than by granting broad admin roles. Roles are so Knowledge Management v2!

This article aims to clarify some of the confusion around knowledge permissions and management practices; it applies to where article versioning and checkout is enabled.

Why this matters?

Governance. Applying least-privilege access helps separate knowledge administration from knowledge contribution. Combined with ownership groups, this creates clearer accountability for content maintenance while avoiding unnecessary administrative access.
AI readiness. For teams preparing knowledge for AI and self-service, access design is especially important. Content should be accessible to the intended audience, while sensitive or restricted knowledge remains governed through explicit criteria. Review access alongside content quality, ownership, and lifecycle controls as part of AI-readiness activities. The benefit is stronger governance and appropriate access.

Spoiler

Principle: User criteria determine who should have access. Ownership groups determine who is responsible for maintaining specific content.

Principle: User criteria determine who should have access. Ownership groups determine who is responsible for maintaining specific content.

Roles and user criteria, in plain terms

Think of a building, a large hotel. The knowledge_admin role is a broad administrative key, so granting one gives far more access than a task needs. If each wing of the building is a knowledge base, user criteria can be thought of as key cards for each wing the user works in.

Ownership groups, in plain terms

An ownership group is a maintenance crew assigned to a specific room (or rooms), and each room is one article. The crew can repair, approve, and sign off the work in that room. It’s role applies only to that room, and it doesn't open the rest of the building. An ownership group also avoids a single point of failure. If one named owner leaves or is unavailable, the article can stall with no one to approve or update it. A group with several members keeps the article maintained.

Two levels of control

Access works at two levels, and they combine.

Knowledge base level: User criteria on the knowledge base sets who can read and who can contribute across every article in that knowledge base.
Article level: You can add user criteria to an individual article to restrict who can read it. Ownership groups also work at this level, giving their members edit rights on specific articles. Ownership group doesn't apply across the knowledge base.

Figure 1 shows the knowledge base level.

Figure 2 shows the article level.

How the rules combine

Reading: A user reads an article only if they pass the knowledge base read rules and any article-level read rules. A Cannot Read rule at either level blocks reading for ordinary readers.
Contributors: Knowledge base contribute access can take precedence over article-level read criteria. This behavior is configurable; see Important configuration considerations.
Editing and checkout: With an ownership group, only its members can contribute to that article, even if others have Can Contribute on the knowledge base. Without one, editing or checking out needs Can Contribute on the knowledge base. Whether authors and revisers keep contribute access after publication on articles with an ownership group is also configurable; see Important configuration considerations.

Example: an IT service desk

A service desk might use three knowledge bases, each with its own user criteria:

IT Self-Service is readable by all staff. The Service Desk can edit it.
Service Desk procedures is readable and editable by the Service Desk only.
Security runbooks is readable by the Service Desk, so agents can follow escalation steps. It is editable only by the Security team.

IT service desk: knowledge base access, plus an ownership group on one article. Each knowledge base has its own user criteria. IT Self-Service is the customer-facing self-help base, so all staff can read it while only the Service Desk can edit it.
A Service Desk agent can check out a published article in Service Desk procedures through Can Contribute on that knowledge base, as long as the article has no ownership group, and without needing the knowledge_admin role.
Ownership groups add a finer layer. Suppose the P1 network outage article in Service Desk procedures has a Network Team ownership group attached. Only that group's members can edit it, so Service Desk agents can no longer check it out through knowledge base access. The Network Team doesn't gain edit access to the rest of the knowledge base.

Recommended approach

Spoiler

Principle: Avoid granting broad administrative roles simply to enable knowledge contribution activities. Use user criteria to manage knowledge base access, and use ownership groups where article-specific responsibility is required.

Principle: Avoid granting broad administrative roles simply to enable knowledge contribution activities. Use user criteria to manage knowledge base access, and use ownership groups where article-specific responsibility is required.

Design access by knowledge base. Define who can read and contribute using user criteria. Use Can Read for viewing. Can Contribute is needed for creating, editing, or checking out articles. You can target users, groups, roles, companies, locations, or departments.
Apply least privilege. Do not grant knowledge_admin solely to allow users to create, edit, or check out knowledge. Reserve it for genuine knowledge administration.
Establish clear article ownership. Use ownership groups for articles that need defined maintenance responsibility. Use a group rather than a single named owner so the article isn't blocked when one person is unavailable. Attach a group to each article it should own. Members can then edit, approve, publish, and retire that article, subject to the configured knowledge workflow.
Use article restrictions selectively. Add article-level criteria only when one article must be hidden from some users who can otherwise read the knowledge base.
Test using real personas. Use User Criteria Diagnostics to inspect user-criteria and domain-based access, then test the actual read, edit, and checkout actions with representative non-admin users. Clear the cache or log out between tests, since results can differ from what users see.
Diagnose exceptions before expanding access. If checkout still fails, investigate conflicting user criteria, ownership group membership, article state and versioning, ACLs, and workflow restrictions before granting broader permissions. Remember that a Cannot Contribute rule overrides a Can Contribute rule, so check for conflicting rules first.

Important configuration considerations

These settings change how the access model behaves. Review them before rollout.

Enable ownership groups. Confirm the Knowledge Management Advanced plugin (com.snc.knowledge_advanced) is active, then enable glide.knowman.ownership_group.enabled. Add the Ownership Group field to the article form if needed. The plugin is automatically activated for new customers starting with Xanadu. It also provides additional features like article quality index (AQI) reviews and article templates.
Create a new ownership group or reuse an assignment group. To create a new group, use the ownership group form (All > Knowledge > Ownership Groups > Manage Group, then select Create Ownership Group). A knowledge_admin approves it. To reuse an existing assignment group, add Knowledge to its Type field, assign a manager with the knowledge_group_manager role, and add knowledge_group_member in the group's Roles related list.
Apply article read criteria to contributors. Set glide.knowman.apply_article_read_criteria to true to make article-level read criteria apply to contributors. It defaults to false.
Keep contribute access after publication. On articles with an ownership group, authors and revisers lose contribute access after publication unless glide.knowman.ownership_group.override is enabled.