Creating articles with different read access levels inside a single Knowledge Base

[Aerin]

I'm getting different answers from different sources about whether this is even possible or how, so I'm hoping you can share your experience with me. I'm looking for OOTB or very, very low levels of customization in the San Diego release.

For example, say that I want to create an IT Support Knowledge Base. Inside this KB, I'd like there to be "self-service" articles that anyone within the organization can read. But I'd also like to include articles with information that isn't safe to share generally, that only the IT Support teams can read.

I'm thinking that maybe there is a way to set up a template so that authors can choose from pre-set reader access options? Or maybe have two templates with that same formatting, but each set to publish to a different reader group? Or maybe there's a third option I haven't thought of?

I'd love to hear your experiences with the both the functionality of achieving this and any pain points with doing it that we should consider before going down that road. Thanks in advance.

[Lauren Methena · Accepted solution]

Hello! What we've done (and it takes a little work to set up but it's easy to use once implemented) is set up groups based on ITIL roles. 

Whatever you decide to use as your criteria for creating groups, if you create your different audiences, then you just choose the groups you want to have access in your Can Read field when setting up your article.

The great thing about setting it up with ITIL roles is that for us, these roles are updated automatically by IT, so we don't have to do manual updates on our end. (We only have 3 groups - enterprise level, leaders/managers, and HR.)

However you decide to set up and then  maintain your user groups within ServiceNow, setting them up and then adding them in the Can Read field has been the way to go for us - for four years now. 

What kind of criteria are you looking to sort by? Role? Location? 

Thanks so much! Please feel free to post follow up questions and mark as helpful if you find it so. 🙂

[Pam Calvey · Accepted solution]

We have 4 text boxes, and access is granted to them via user criteria. Level 0 is self-service (we are company only) and everyone in the company sees it by default. The other 3 levels also have defaults. Agents and specific higher level support teams see Level 1. Only the high level teams see Level 2. Only Admin and recovery/problem mgmt see Level 3 by default but the idea is that the high level teams add their user criteria to the Can Read Level 3 fields if they choose to hide their info from other teams. So as the levels go up, the amount of people who can see it go down. We also have teams outside the default who can add thier UC to any of the 3 Can Read restricted text levels. How much work that took to build, I don't know. It was set up by our configuration company when we launched SN in 2017. It can affect the approval process. For instance if the Document owner group doesn't have a knowledge manager listed in the approval tab the article will default to published when submitted for review, doesn't go through an approval process. 

We also have 3 knowledge bases that are Level 0 only. One is open to anyone in the company. Another is restricted to ITIL role only. A third is to Security teams only.  Our form still lists all 4 text boxes, but teams are trained to only use the first one. 

[Lauren Methena · Accepted solution]

Hello! What we've done (and it takes a little work to set up but it's easy to use once implemented) is set up groups based on ITIL roles. 

Whatever you decide to use as your criteria for creating groups, if you create your different audiences, then you just choose the groups you want to have access in your Can Read field when setting up your article.

The great thing about setting it up with ITIL roles is that for us, these roles are updated automatically by IT, so we don't have to do manual updates on our end. (We only have 3 groups - enterprise level, leaders/managers, and HR.)

However you decide to set up and then  maintain your user groups within ServiceNow, setting them up and then adding them in the Can Read field has been the way to go for us - for four years now. 

What kind of criteria are you looking to sort by? Role? Location? 

Thanks so much! Please feel free to post follow up questions and mark as helpful if you find it so. 🙂

[Aerin]

Ok, so that is possible. The company we are working with to configure our Knowledge is making it sound like this is hugely complicated to both set up and maintain and are advising strongly against it. Interesting. Are your articles created by a specific group or is it fairly open - I'm wondering how hard you found it to train people to set the field correctly?

[Lauren Methena]

A little bit of both. In IT, it's a little more wide open. I'm on the HR side. A small group contributes articles. And I as chief knowledge manager act as the main gatekeeper for entering articles. However, when we have assembled project teams and trained others on entering the articles, training people to set the field correctly (and some of the other practices we follow, such as putting a notice at the top of the article that alerts readers to the limited audience) was very easy. There wasn't any confusion.

I can understand if the maintenance part is harder. It all depends on where ServiceNow is pulling information from. But there must be a way to run a report or do something on a weekly, monthly (whatever cadence you need) basis to make sure users and groups are up to date.

[PatrickBauer]

Hi,
We are using the KCS template. Article ownership is our "IT KCS Team"

Contributors set the article visibility using the "Can read" field when publishing :   
- "IT members" (by default) or
- "ALL company"  ; if / when criteria are met  ( public / portal )

Hope this helps
Cheers