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. 

[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. 

[Aerin]

Fabulous, thank you! That makes sense.

[Jenna Palacio · Accepted solution]

Hello.  I rolled out a version of ServiceNow knowledge where we had restricted 'views'/access. We moved from a knowledge application where users had different access based on where they were located (it was a global company) and if they were HR or IT. This was done to keep people from accessing information they shouldn't (IT from seeing sensitive HR documents, people in the US from seeing EMEA procedures, etc.). It took a bit of configuration, but what was eventually decided was that access would be based on roles. You would have a location role (NA, Germany, France, Canada, etc.), a work role (HR, IT), and possibly another work role (internal, external, customer). 

Since we had knowledge teams around the globe, we only had a few templates (for IT, HR, and self-service), and anything in workflow rolled up to the appropriate KM team based on the geographic role (EMEA IT KM team, NA IT KM team, APAC HR KM Team...). Honestly, the most effort was in figuring out who would be assigned what roles and creating the spreadsheets to upload so everyone was assigned to them. It worked great. 

[Leri Andrews]

Hi

For the scenario you describe it seems easiest to just have a tiered knowledge-base set up.  A self-service knowledge base open to all and a Tier 1 Knowledge-base open to users with an ITIL role.  The user criteria is applied at the knowledge-base level so there's no need to instruct your authors on which user criteria to apply every time they create an article. Simple to maintain and effective.

However, within each knowledge-base you could apply criteria at the article level if desired (e.g. manager articles, articles visible to only people in Poland). If you're not using knowledge templates and have chosen to enable knowledge blocks, you can even construct a single 'article' with sections viewable to different users.

Things to be aware of:

1. There's a weird hierarchy to user criteria e.g. if someone meets both the 'can read' and 'cannot read' criteria then 'cannot read' wins (I think!), and 'can contribute' on knowledge base trumps 'cannot read' on article (or is it the other way round? - my brain hurts)
2. Scripted user criteria can cause performance issues, especially for portal search (it checks what you can see before showing the results, which can take a long time with lots of scripted criteria and articles)
3. User criteria don't 'stack'.  If you have two can read criteria listed, you only have to meet one to see the article. 
4. IT users often send articles to people who can't see them. Hard to solve even with labelling and training.
5. The default message used for unviewable articles (for whatever reason, including retired ones) can be unhelpful
6. Knowledge blocks are (I've heard) rather flawed from an administration point of view. Avoid right now.

[Vickie Runyon]

Here's our experience...

We had three separate knowledge bases: 1. Public - available to all employees 2. After Hours Support - available to our vendored after-hours service desk 3. IT Only - only visible to our IT department

This was problematic in that those that were writing articles were not sure which KB to use. It also led to lots of duplicate information for issues that had a self-service component but if that doesn't work then here's what after-hours can do and then what IT can ultimately do to fix the same issue.

We switched to using the already existing Public KB and building a template (we follow KCS methodology so we started with that OOB template) and added fields for After Hours Resolution, After Hours Escalation, IT Resolution, and IT Escalation. We applied ACLs to those fields and used group membership to allow access via the ACLs. So, the entire article is visible to IT. After Hours vendor can only see the Public fields and the After Hours fields. All employees can only see the Public fields (Issue, Cause, and Self-Service Resolution).

We just started down this path earlier this year but so far it's been working out very well.

The only drawback so far has been having to rewrite/recreate an existing article using the new template and abandoning (retiring) the prior article. ServiceNow does not have a way to move an existing article from one template to another. We have been putting the previous article number in meta so that if the previous article number is out there, someone will find it by searching. However, any permalinks that might have been shared for those articles will not lead you to the new one.

We are US based and only write articles in English.