Managing access to knowledge bases and knowledge articles
Summarize
Summary of Managing access to knowledge bases and knowledge articles
This guide explains how ServiceNow knowledge administrators, knowledge base managers, or owners can control user access to knowledge bases and articles by assigning user criteria and roles. Access is managed at two levels:
Show less
- Knowledge base level: Controls who can read (view) and contribute (create, modify, retire) articles.
- Knowledge article level: Controls read access to individual articles.
User criteria, introduced in Knowledge Management v3, are the preferred method to manage access, replacing roles used in earlier versions.
Key Features
- User Criteria Types:
- Cannot Contribute: Denies contribute access at knowledge base level.
- Can Contribute: Grants contribute access at knowledge base level.
- Cannot Read: Denies read access at both knowledge base and article levels.
- Can Read: Grants read access at both knowledge base and article levels.
- Access Logic: Access is denied if conflicting user criteria (e.g., both Can Read and Cannot Read) apply at the knowledge base or article level.
- Special Privileges:
- Knowledge administrators have full read and contribute access and can modify knowledge base definitions.
- Knowledge base owners and managers have full access and can assign criteria but with some restrictions if article versioning is enabled.
- Ownership group members can fully manage specific articles.
- Explicit Roles Plugin: When activated, predefined user criteria based on internal roles (sncinternal) are automatically added to new knowledge bases for refined access control.
- System Properties: Several properties influence access behavior:
- glide.knowman.search.applyrolebasedsecurity: Allows overriding role-based security to use user criteria only.
- glide.knowman.blockaccesswithnousercriteria: Controls contribute/read access when no user criteria are set.
- glide.knowman.applyarticlereadcriteria: Determines whether article-level criteria override knowledge base-level contribute/read access.
- User Criteria Diagnostics: A feature to verify what access users have to knowledge bases or articles after setting criteria.
Practical Application for ServiceNow Customers
- Control Access Precisely: Use user criteria to specify who can read or contribute to knowledge bases or individual articles, enhancing security and relevance.
- Leverage Special Privileges: Assign knowledge administrators and managers with appropriate permissions to maintain governance.
- Use System Properties Mindfully: Adjust system settings to refine access control behavior, especially when migrating from older versions or implementing scoped knowledge bases.
- Validate Access: Utilize the User Criteria Diagnostics tool after configuration to ensure users have intended access levels.
- Explicit Roles Integration: When using plugins like Customer Service, understand how explicit roles affect access and may require running fix scripts for legacy knowledge bases.
Next Steps
- Create and assign user criteria to knowledge bases and articles to enforce access policies.
- Configure relevant system properties to align knowledge management access with organizational requirements.
- Periodically use diagnostics to audit and verify user access permissions.
Determine whether certain users or categories of users can access knowledge bases and knowledge articles by controlling contribute and read access.
- Read access determines the ability to view knowledge articles in a knowledge base.
- Contribute access determines the ability to create, modify, and retire knowledge articles in a knowledge base.
As a knowledge administrator, manager of a knowledge base, or owner of a knowledge base, you can assign user criteria, or roles, or both, to control read access at the knowledge article level.
Try to use only user criteria, which were introduced in Knowledge Management v3, to control access to knowledge articles. Roles were used for this purpose in Knowledge Management v2. If no user criteria is selected for a knowledge base, all users can read and all users with roles can contribute to that knowledge base.
User criteria for knowledge access
As a knowledge administrator, manager of a knowledge base, or owner of a knowledge base, you control access to knowledge bases or knowledge articles for a user through user criteria, which are described in the following table.
| User criteria | Result |
|---|---|
| Cannot Contribute | Cannot contribute (that is can't create, modify, or retire) knowledge articles within a knowledge base. The Cannot Contribute user criteria is available only for knowledge bases. |
| Can Contribute | Can contribute (that is can view, create, modify, or retire) knowledge articles within a knowledge base. The Can Contribute user criteria is available only for knowledge bases. |
| Cannot Read | At the knowledge base level, cannot view knowledge articles within a knowledge base. At the knowledge article level, cannot view a knowledge article. |
| Can Read | At the knowledge base level, can view knowledge articles within a knowledge base. At the knowledge article level, can view a knowledge article. |
The access to knowledge base and its articles are defined based on the user criteria status for a user as described in the following table.
| Status | Access |
|---|---|
| The user matches both Can Contribute and Cannot Contribute at the knowledge base level | The user is denied contribute access to the knowledge base and its articles. |
| The user matches both Can Read and Cannot Read at the knowledge base level | The user is denied read access to the knowledge base and its articles. |
| The user matches Can Read at the knowledge base level and Cannot Read at the knowledge article level | The user is denied read access to the knowledge article. |
| The user matches Cannot Read and Can Read at the knowledge article level | The user is denied read access to the knowledge article. |
Users with special knowledge privileges
Users with special knowledge privileges aren't evaluated based on user criteria and have knowledge bases and knowledge articles access as described in the following table.
| User | Access |
|---|---|
| Knowledge administrator |
Note: This access doesn't apply to scoped knowledge bases. For more information, see
Scoped knowledge bases. |
| Owner of a knowledge base |
|
| Manager of a knowledge base |
Note: If the article versioning feature is enabled, the manager of a knowledge base
can’t modify knowledge articles of other authors that are in the
Draft state. For more information, see Article versioning. |
| Members of an ownership group associated with a knowledge article | Read, modify, approve, and retire that knowledge article (see Ownership groups). |
Explicit roles and user criteria
Explicit roles (snc_external and snc_internal) are added to your instance when your administrator installs a plugin, such as the Customer Service plugin (com.sn_customerservice), that also activates the Explicit Roles plugin (com.glide.explicit_roles). If you create a knowledge base with the Explicit Roles plugin (com.glide.explicit_roles) activated, the application automatically adds the following predefined user criteria at the knowledge base level:
- Users with 'snc_internal' role – Added to the Can Read user criteria enabling only users with the snc_internal role have read access to the knowledge base.
- Users with snc_internal' and another role – Added to the Can Contribute user criteria enabling only users with the snc_internal role and at least one additional role have contribute access to the knowledge base.
When you upgrade to product versions (from Rome onwards) that offer the Explicit Roles plugin (com.glide.explicit_roles), the predefined user criteria Users with 'snc_internal' role and Users with 'snc_internal' and another role aren't automatically added to any existing knowledge bases created prior to the activation of the Explicit Roles plugin. To add these predefined user criteria to an existing knowledge base, run the Fix unsecured knowledge bases fix script. For more information about explicit roles and fix scripts, see Explicit Roles and Fix scripts.
Determining contribute access to a knowledge base and its articles using user criteria
When either Cannot Contribute isn’t set or a user doesn’t match Cannot Contribute and additionally Can Contribute is not set, the glide.knowman.block_access_with_no_user_criteria property value is further evaluated to determine contribute access, as explained in the following table.
| Property value | Result |
|---|---|
| true | No user has contribute access to the knowledge base except users with special knowledge privileges. |
| false | All users, including unauthenticated users, with at least one role can
contribute to the knowledge base. If the Explicit Roles plugin (com.glide.explicit_roles) is activated, users who have at least one role other than snc_internal can contribute to the knowledge base. To check knowledge bases accessible to unauthenticated users, use the User Criteria Diagnostics feature. For more information, see Configure access to knowledge bases for unauthenticated users. |
When a user has contribute access to a knowledge base, the glide.knowman.apply_article_read_criteria property is evaluated to determine contribute access to an article in the knowledge base, as explained in the following table.
| Property value | Result |
|---|---|
| true | Article-level read access overrides the default contribute permission granted by contribute access at the knowledge base level. |
| false | Contribute access at the knowledge base level takes precedence over article-level user criteria and the user has contribute access to every article in the knowledge base. |
Determining read access to articles in a knowledge base using user criteria
When either Cannot Read isn’t set or a user doesn’t match Cannot Read and additionally Can Read is not set, the glide.knowman.block_access_with_no_user_criteria property value is further evaluated to determine read access, as explained in the following table.
| Property value | Result |
|---|---|
| true | No user has read access except users with special knowledge privileges and users who have contribute access to the knowledge base. |
| false | All users, including unauthenticated users, have read access to the knowledge
base and the article-level user criteria are further evaluated. To check knowledge bases accessible to unauthenticated users, use the User Criteria Diagnostics feature. For more information, see Configure access to knowledge bases for unauthenticated users. |
When a user has contribute access to a knowledge base, the glide.knowman.apply_article_read_criteria property is evaluated to determine read access to an article in the knowledge base, as explained in the following table.
| Property value | Result |
|---|---|
| true | Article-level read access overrides the default read permission granted by contribute access at the knowledge base level. |
| false | Contribute access at the knowledge base level takes precedence over article-level user criteria and the user has read access to every article in the knowledge base. |