========Update Oct 15 2019 =========
This feature is now supported OOB through Article Templates (Available via Knowledge Advanced plugin).
========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:
- On Knowledge form, configure an additional field. In this case, we are creating a custom string field e.g. "Additional Comments"
- 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.
-
- 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.
- 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.
- Impersonate any ITIL user and confirm that the added field is available.
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