Policy & Compliance with Knowledge Management- user criteria differences

[Adam43]

Hey all- my GRC team is publishing their Policy & Compliance documents into multiple categories under the GRC Knowledge Base.  They have some categories that are suitable for public consumption (snc_internal) and others that need restricting for grc type roles.  Given that GRC properties integrate to one knowledge base, and KBM does not allow user criteria to be applied at the category level- I'm curious what solutions this community would suggest?

They'd really rather not manage at the article level, and moving/duplicating the articles manually into another location sort of defeats the purpose of the integration between policy&compliance and the KBM modules.

[Community Alums · Accepted solution]

Hi @Adam43 ,

It's not possible OOTB!! However, you can play with ACL in the category table level.

Please follow the solution: https://www.servicenow.com/community/now-platform-forum/knowledge-base-user-criteria-at-the-category...

[Adam43]

yeah, not possible OOTB.  ACL and designing at the KB level just doesn't make it very flexible in terms of organizing content flexibility.  adding user criteria functionality to the category level would enhance ability to minimize unnecessary duplication of bases and categories, merely for the purpose of handling visibility restrictions.  This seems like such a no-brainer. 

Does anyone know how to add the actual 'user criteria' functionalities?  are those recognized in scripted ACLs or business rules or what?

[Tammy Simmons]

To give our GRC team the flexibility to specify the audience for policy knowledge articles as needed, I implemented the following steps below. Note: I did not have any existing KB articles in the 'Governance, Risk, and Compliance' knowledge base. 

Any suggestions for improvement are most welcome.

1. Custom Field Creation:

• Create a custom field titled 'User Criteria' on the Policy Article Template table [sn_compliance_article_template].
  • Column label: User Criteria
  • Column name: u_user_criteria
  • Type: Reference
  • Reference: User Criteria [user_criteria]
  • Mandatory: false
  • Add the new field to the form layout of the 'Article Template' under the 'Type' field.

2. User Criteria Setup:

• Create the necessary user criteria for the target audience, if not already present.

3. Important Note:

• For this functionality to work as intended, the same user criteria records must be added to the 'Can Read' related list of the 'Governance, Risk, and Compliance' knowledge base. It is essential to review any existing knowledge base articles to ensure they have the correct 'Can Read' user criteria applied.

4. Template Creation:

• Create a copy of the OOB 'Example Article Template' for each user criteria template needed:
  • Name: Example – 'End User Article Template'
  • Type: XML
  • User Criteria: Any User (this should correspond with the name being used for this article template audience)
  • XML: Same as the OOB 'Example Article Template' – no changes
  • Is default: false

5. Enforcing Article Template Selection:

• I did not set 'Is default' on any of the article templates to ensure that the GRC team selects a template when creating a new policy record.
• I modified the OOB 'Example Article Template' to serve as one of the user criteria templates. This update prevents it from appearing in the list, as the Article Templates table does not include an 'Active' field.
• Important Note: Removing the default may update existing policy records by clearing the value, so please be aware of this.

6. Automation with Business Rule and Script Include:

• Create a custom business rule and script include to set the 'Can Read' user criteria on the knowledge base articles. See below for details.

Business Rule:
Name: Update Published KB Article Access
Table: Policy [sn_compliance_policy]
When: After
Update: true
Filter Conditions: Published policy changes AND
                   Published policy is not empty
Script:
(function executeRule(current, previous /*null when async*/ ) {
    // Call updateArticleAccess, passing in the policy GlideRecord
    if (!current.kb_article.nil()) {
        new global.GRCArticleAccessUpdate().updateArticleAccess(current);
    }
})(current, previous);

Script Include:
Name: GRCArticleAccessUpdate
Application: Global
Accessible from: All application scopes
Script:
var GRCArticleAccessUpdate = Class.create();
GRCArticleAccessUpdate.prototype = {
    initialize: function() {},

    updateArticleAccess: function(policyGR) {
        // Get the article template's user criteria
        var articleTemplate = new GlideRecord('sn_compliance_article_template');
        if (!articleTemplate.get(policyGR.article_template)) {
            gs.warn("Article template not found for Policy: " + policyGR.sys_id);
            return;
        }

        var userCriteriaSysId = articleTemplate.u_user_criteria; // Get the user criteria Sys ID

        if (!userCriteriaSysId) {
            gs.warn("No user criteria defined on article template for Policy: " + policyGR.sys_id);
            return;
        }

        // Find the published Knowledge Article associated with this policy
        var kbArticle = new GlideRecord('kb_knowledge');
        kbArticle.addQuery('sys_id', policyGR.kb_article); // Directly use kb_article sys_id
        kbArticle.addQuery('workflow_state', 'published');
        kbArticle.query();

        if (kbArticle.next()) {
            // Set Assignment Group and Draft Group to CorpIT GRC
            var grcAssignmentGroup = gs.getProperty('corpit.grc_assignment_group');
            kbArticle.u_assignment_group = grcAssignmentGroup;
            kbArticle.u_draft_group = grcAssignmentGroup;
            // Update the can_read_user_criteria field if necessary
            var canReadCriteriaList = kbArticle.can_read_user_criteria ? kbArticle.can_read_user_criteria.split(',') : [];
            if (!canReadCriteriaList.includes(userCriteriaSysId)) {
                canReadCriteriaList.push(userCriteriaSysId);
                kbArticle.can_read_user_criteria = canReadCriteriaList.join(',');
                gs.info("Updated can_read_user_criteria for Knowledge Article: " + kbArticle.getUniqueValue());
            }
            kbArticle.update(); // Save changes to the Knowledge Article
        } else {
            gs.warn("Published Knowledge Article not found for Policy: " + policyGR.sys_id);
        }
    },
    type: 'GRCArticleAccessUpdate'
};

[Jacques Clement]

That might be too simplistic, but would it not be easier to just use different Knowledge Bases, each having it own user criteria requirements?