Controlling Knowledge Article field-level visibility

[Sarup Paul]

========Update Oct 15 2019 =========

This feature is now supported OOB through Article Templates (Available via Knowledge Advanced plugin).

Article Templates

Restricted fields

========Update Oct 15 2019 =========

We received a few questions on how to limit the visibility of specific content, to specific audiences for knowledge articles, without having to create a new article. For example, if you have an article, in which different teams in your support organization (e.g. Tier 0, Tier 1, and Tier 2), should see different content- it is possible to separate that out in a single article. The obvious benefit is that you would not need to maintain multiple articles on the same subject matter for different audiences, which increases the chances of inconsistent information.

For example, see the hierarchical access structure below. The Tiers 0-2 represent your users with different roles (access control). Let's say you are creating an article on "Issues with wifi in the break room area." You can write a single article, with fields/sections of the content that are

• Visible to all i.e. Tier 0. This could have "Instructions on how to stop/start your wifi on your device"
• Only visible if you are Tier 1 or higher. This could have Tier 1 agent instructions on "Instructions on how to remotely reset the wifi access point"
• Only visible if you are Tier 2 or higher. This could have Tier 2 agent instructions "How to call the network service provider to service the wifi access point"

This is achievable with the use of Field Level Access Control Lists (ACLs), on a field in the Knowledge table, that you want to secure by role.

 

How ACLs work

After the Field-Level ACLs have been setup, you'll need to customize kb_view to include the new field.   Since the Field-Level ACLs have been applied, only users who have Tier 1 or Tier 2 access, will be able to see this information on the kb_view UI page.

How to add field level security to Knowledge Articles

The example below shows a two-level field level access control, where ITIL role has access to a field that a non-ITIL role does not:

1. On Knowledge form, configure an additional field. In this case, we are creating a custom string field e.g. "Additional Comments"

   

2. Add a field level ACL that gives READ access to only users having "ITIL" role.

• Add the field on kb_view UI Page (article view).
• If you are using the out-of-box page, this can be done via UI Macro > kb_view_common_content
• Add a code snippet in the xml, as show below

Testing a new field on a Knowledge Article

So now that we have both the Field configured and the Article view UI macro updated, it's time to test. We want to see that content meant for ITIL user is only available to them, and not to non-ITIL user.

1. 1. Impersonate any ITIL user and confirm that the added field is available.

      The ITIL user should be able to see the "Additional Comments" field on the knowledge table in the platform as well as in the knowledge article view page.

   2. Next, impersonate any Non-ITIL user. The Non-ITIL user should be able to see the "Additional Comments" field on the knowledge table in the platform as well as in the knowledge article view page.

      

      

Using Field level ACLs, you can easily setup the same article to provide different sets of information, based upon the user's roles. This can greatly reduce the need to have duplicate content, increasing the need for extra maintenance and overhead. Hope you found this useful. We are planning to add easier configurability for implementing Article Section/Attribute level security in the upcoming releases.

Thank you to Authors/Contributors: britt.champeau abhishek.rakshe

[marcus_redfern]

Thanks Goran - your book is very useful too !

[User399545]

Hello Sarup Paul, 

Please how can i add fields to the article view page. i followed the instructions provided above and it didn't work.

[Pravallika1]

Hi Sarup,

I created two custom fields on standard article template.Those fields are not visible on kb_article_view on the portal.Please suggest what to be modified to show the fields on the article in portal

[Randall King]

We are having the same problem. Did you find a solution yet?

[Aerin]

Can someone clarify if this is still supported? The Devs on my team weren't able to make it work, so we put a ticket into SN support. They responded that using ACLs this way left a security gap, that they added security to close the gap, but it didn't cover HTML fields. 

They suggested that we could put in a request to have it added as a feature. So, it was a feature, but now it's not? I just need to know whether in theory it should be working and I should keep poking to figure it out, or if it's just no longer an option. Thank you.

[Randall King]

We are using San Diego and it's working for us. To clarify, are you talking about restricting access to one particular HTML field on a custom knowledge template to people with a particular role?

[Aerin]

Sorry, I should have clarified. We are just about to update to Rome. 

Yes, I'd like to build a custom template where the articles created are viewable by everyone, with one or two fields that can only be viewed by people with a specific role.

[Randall King]

I'll describe what we are doing, and maybe that will help.

We are using User Criteria Records for the most part, which is what I think they recommend now for knowledge permissions (https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0550924).

On the record for the knowledge base, we use the "Can Read" related list to add the User Criteria Records. This controls overall permission for the knowledge base.

Next, we went to Knowledge > Administration> Article Templates and created the templates that we wanted. We added the field "Can Read" to the form. This allows us to control permissions on a per-article basis. Again, this uses User Criteria Records.

For field-level access, we went to the form for the knowledge template, right-clicked the field name, and went to the dictionary. Elevate permissions to security admin. Then, add a new ACL for the field to restrict access to the particular field.

These steps worked for us. We have a knowledge base that's publicly viewable, and within that we have articles only visible to current students, faculty, and staff. Further, there are fields that only IT employees can view within those same articles.

[Aerin]

Thank you! I'm going to take your comment back to my team and see if what you describe varies from what they've been trying to do.

[Aerin]

It turns out that the procedure you've outlined is what we've tested. It works in the sense that when viewing the article, the restricted fields are only shown to people with the correct criteria. However, the information in the restricted fields isn't withheld in other situtions - for instance, it can be seen in the search results in the portal. Obviously, this isn't the outcome we're looking for.