Knowledge Management Governance, Roles, Ownership Groups and Access Model - HRSD
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi Experts,
We recently conducted a workshop on ServiceNow Knowledge Management in HRSD and are looking for guidance on a few topics related to governance, access management, roles, ownership, and Knowledge Blocks. We would appreciate any best practices, recommendations, or real-world implementation experiences.
1. Ownership Groups vs. "Can Contribute" User Criteria
We are trying to understand the purpose and behavior of Ownership Groups when Can Contribute User Criteria are already configured at the Knowledge Base level.
Specifically:
- If a user matches the Knowledge Base Can Contribute User Criteria but is not a member of the article's Ownership Group, can they still edit or contribute to that article?
- If a user is not included in the Knowledge Base Can Contribute User Criteria, but is a member of the article's Ownership Group, can they edit, approve, publish, or retire that article?
- If a user is neither part of the Knowledge Base Can Contribute User Criteria nor a member of the Ownership Group, I assume they cannot contribute to the article. Is this correct?
- What is the practical use case for Ownership Groups when contribution access is already controlled through Knowledge Base User Criteria?
- Are Ownership Groups primarily intended for article ownership and governance, or do they override Knowledge Base contribution permissions?
- Is there a defined precedence between Knowledge Base User Criteria and Ownership Group membership?
2. IAM Integration and Role Management
Our organization uses a centralized IAM solution to manage access.
We observed that when a user is assigned as a Knowledge Manager on a Knowledge Base, the required ServiceNow role is automatically granted.
This raises a few governance questions:
- Is it considered best practice to manage Knowledge Management roles through IAM-managed groups?
- Should roles such as knowledge, knowledge_manager, and knowledge_admin be requested and provisioned through IAM?
- Or is it common practice to rely on the out-of-the-box automatic role assignment performed by ServiceNow?
- How do other organizations align Knowledge Management access with centralized IAM governance?
3. Knowledge Management Roles and Responsibilities
We would like clarification on the standard ServiceNow Knowledge Management roles and how they should be mapped to a business operating model.
Specifically:
- What are the standard ServiceNow Knowledge Management roles and their intended purpose?
- Which roles are typically assigned to:
- Knowledge Base Owner
- Knowledge Manager
- Knowledge Contributor / Author
- What are the recommended responsibilities and permissions for each role?
- Are there any best practices for role assignment and segregation of duties?
4. Knowledge Blocks and Governance
We are also looking for clarification on the governance and access model for Knowledge Blocks.
Specifically:
- Are there any dedicated ServiceNow roles for creating, maintaining, and managing Knowledge Blocks?
- Do Knowledge Blocks use the same roles as Knowledge Articles?
- Who is typically responsible for maintaining reusable Knowledge Blocks in an enterprise setup?
- How are permissions inherited between Knowledge Bases, Knowledge Articles, and Knowledge Blocks?
- Are there any recommended best practices for ownership and governance of Knowledge Blocks?
Any best practices, lessons learned, or examples from real-world implementations would be greatly appreciated.
Thank you in advance for your support and insights.
- Labels:
-
Architect
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
17m ago
Hey @bhaavani :
In practice, Ownership Groups act as article-level governance overrides rather than simple read/write access list filters. If a user matches the KB Can Contribute criteria but isn't in the Ownership Group, they can still edit the article unless your instance is configured to restrict edits strictly to group members; conversely, an Ownership Group member can edit, approve, publish, and retire their assigned article even if they lack broader KB-level Can Contribute permissions. For enterprise IAM and role management, it is best practice to manage base roles (knowledge, knowledge_manager) via IAM-provisioned Active Directory/Entra groups synced to ServiceNow, while reserving the KB Owner field for routing and automated operational assignments. In HRSD, Knowledge Blocks share the same underlying knowledge role as articles but inherit governance from the host Knowledge Base: in the sense block maintenance typically falls to HR Subject Matter Experts or Knowledge Authors who own the specific modular content (such as localized benefits policies).
To build a scalable operating model, map KB Owners to HR Service Delivery Directors (overall strategy/taxonomy), Knowledge Managers to HR Operations Leads (workflow approvals/quality audits), and Knowledge Contributors to Tier-2/3 HR SMEs (authoring articles and reusable blocks). When designing Knowledge Blocks, avoid fragmenting simple content: reserve blocks for high-value scenarios like multi-country compliance disclaimers or role-specific benefits details that are reused across 10+ HR articles. To prevent security gaps or orphan content, enforce strict segregation of duties where IAM controls broad baseline platform access, while automated platform workflows route review tasks directly to assigned Ownership Groups, ensuring every piece of HR knowledge remains compliant, up to date, and 'audit-ready'.