Controlling access to only a few articles in a Knowledge Base

[Renata82]

Hi,

I am hoping someone can help me with an article access issue I'm struggling with.

We have a KB Structure separated by regions. In each region we have a number of countries. For each country we have a couple of articles targeting only New Joiners (New Joiners should see only these articles and nothing else) . 

So imagine in our Europe region KB we have 2000 articles, 3 of these articles are for German New Joiners. We want the new joiners in Germany to ONLY see those and nothing else. The other German employees can also see these articles, that's not an issue the issue is to restrict New Joiners from seeing the remaining 1997 articles. We've created good user criteria segregating the New Joiners (call it "German New Joiners User Criteria"), and I know that if we give CAN READ access to this German New Joiners User Criteria, and then go into each one of the remaining 1997 articles that New joiners should not see and give CANNOT READ access to the German New Joiners User Criteria I would achieve what I want, but I think we all can agree this is a very clumsy solution. There has to be a better way to achieve this. Just in the Europe KB we also have 2-3 articles that French new joiners should see (without seeing anything else), and 2-3 KA that Spanish new joiners hould see without seeing other articles, and so forth. If we work with Can Read on KB level and Cannot Read on article level we'll end up putting a million User criteria on article level just in the Europe KB.  I also tried other approaches, such as giving CAN Read access to the KB to the German New Joiners, and then giving Can Read access to the 3 articles to the German New Joiners User Criteria, but all this did is restricted the rest of the Europe users from seeing the 3 articles, but the German New Joiners could still see ALL the articles in the Europe KB and not only the 3 articles targeting them. I also tried "Not" giving specific access to the Europe KB to the German New Joiners, and just giving them Article level CAN READ access to the 3 articles they need to see, but obviously this didn't work either, as they first need to have access to the KB otherwise they can't see articles in the KB even if they have Read access to the articles. 

I really feel like I tried everything I can think of and re-read the Managing access to Knowledge Bases and Knowledge Articles ServiceNow Documentation a number of times, but I cannot think of a better way to achieve what I want then giving Cannot read access to almost 2000 articles, for 10 different User criteria (or creating a new KB for new Joiners and again give Cannot Read user criteria per country articles...), and it's just too much to maintain...

[Kieran Anson]

Hi,

I think the suggestion here would be to alter your knowledge structure if the overhead is to high. Managing access at the article is indeed cumbersome and intended for a limited use-case. Where you have a need to managing access based on a clear distinction of new starter vs non-new starter would inherently lead to it's own knowledge base(s) 

[kaushal_snow]

@Renata82 ,

In ServiceNow you can control access to your Knowledge Bases by creating tailored user criteria for each group (for example German New Joiners), then for the Germany New Joiners set up a separate Germany New Joiners KB (containing just the few targeted articles) and assign the criteria to the Can Read list there, while in your main Europe KB you explicitly add that same criteria to the Cannot Read list so that New Joiners are blocked from the broader content, this way you avoid the very high maintenance of managing Can/ Cannot Read on thousands of individual articles.....

If you found my response helpful, please mark it as ‘Accept as Solution’ and ‘Helpful’. This helps other community members find the right answer more easily and supports the community.

[MaxMixali · Accepted solution]

ServiceNow – Restricting Knowledge Base Access for Regional New Joiners

Problem
You have a Knowledge Base (KB) structured by regions (e.g., Europe) and within each region, you have countries. Each country has a few “New Joiner” articles that should be visible only to New Joiners in that country and not to anyone else. Other users can see all articles normally. You want a scalable solution that avoids maintaining thousands of “Cannot Read” user criteria on individual articles.

Example:
- Europe KB → 2000 articles total.
- 3 of those are for German New Joiners.
- German New Joiners should see only those 3 articles.
- Other employees can see all articles.

Issue
ServiceNow’s Knowledge Access model requires that a user must have:
1. Access to the **Knowledge Base (KB)** itself (via “Can Read” on KB level).
2. Access to the **individual article** (via matching “Can Read” or not being blocked by “Cannot Read”).

If you grant “Can Read” on the KB to a user, they can see *all* articles unless those articles explicitly block them via “Cannot Read.”

This makes fine-grained exclusions difficult to maintain when you have thousands of articles.

---

Recommended Solutions

### Option 1: Create a Dedicated “New Joiners” Knowledge Base (Best Practice)
The cleanest and most maintainable approach is to separate new joiner articles into their own Knowledge Base per region (or even per country if needed).

Example structure:
- Europe KB → general articles for all employees
- Europe New Joiners KB → articles only for new joiners (with country-specific criteria)

Steps:
1. Create new KBs:
- “Europe New Joiners”
- “Asia New Joiners” (etc.)
2. Assign “Can Read” = German New Joiners (User Criteria).
3. Do NOT give those users “Can Read” access to the main “Europe” KB.
4. Keep only relevant “New Joiner” articles in the new KBs.

Advantages:
- No need to maintain thousands of “Cannot Read” entries.
- Access management is simple: each KB has its own targeted user criteria.
- Scales easily to multiple countries/regions.

---

### Option 2: Use Dynamic User Criteria and Metadata Tagging
If you must keep all articles in the same KB (for structural or reporting reasons), use metadata and dynamic filters instead of article-level user criteria.

Steps:
1. Add a field to the article form (e.g., `Country` or `Audience Type`).
- Populate this with values like “Germany”, “France”, “Spain” and “New Joiners”.
2. Create **Dynamic User Criteria Scripts** that restrict visibility based on user’s country and audience type.

Example Dynamic User Criteria Script:
(function() {
var userCountry = gs.getUser().getLocation().country.toString();
var userType = gs.getUser().getRecord().u_user_type.toString(); // e.g. “New Joiner”
var articleCountry = current.u_country.toString();
var articleAudience = current.u_audience_type.toString();

// New Joiners can see only their country + New Joiner articles
if (userType === 'New Joiner' && userCountry === articleCountry && articleAudience === 'New Joiner') {
return true;
}
// Non-New Joiners can see everything
if (userType !== 'New Joiner') {
return true;
}
// Otherwise, deny
return false;
})();

3. Assign this dynamic criteria as “Can Read” at the KB level.

Results:
- German New Joiners see only “Germany + New Joiner” articles.
- Other employees see everything.
- No need to assign 2000+ article-level “Cannot Read” entries.

Notes:
- Requires adding fields and a scripted dynamic user criteria record.
- Works across multiple regions if user profiles contain country data.

---

### Option 3: Conditional Display through Knowledge Blocks (Frontend Control)
If your Knowledge Portal or Employee Center is the main entry point, you can hide irrelevant articles using **contextual search filters** or **portal widgets**.
- Use search sources filtered by “Country” and “Audience Type.”
- The data may still exist but will not appear in search results or widgets for restricted users.
- This is a UI-layer control and should be combined with true ACL/user criteria security if compliance is required.

---

Maintenance & Performance Considerations
| Approach | Pros | Cons |
|-----------|------|------|
| Separate KBs | Simple, scalable, least admin overhead | More KBs to manage |
| Dynamic User Criteria | Single KB, flexible logic | Requires scripting and consistent metadata |
| Article-level “Cannot Read” | Granular, native | Impossible to maintain at scale |
| Portal Filtering | Quick fix | Not a true security control |

---

Recommendation
- For compliance-grade security and scalability, **create dedicated KBs for New Joiners** (by region or country).
- For flexibility and reduced duplication, **use Dynamic User Criteria** to restrict articles in a single KB.
Avoid mass “Cannot Read” criteria — it’s unmanageable long-term and prone to errors.

---

TL;DR
✔ ServiceNow’s access model requires KB-level visibility first, then article-level rules.
✔ To make New Joiners see only specific content, either:
- Create a separate “New Joiners” KB per region, or
- Use **Dynamic User Criteria** based on user metadata (country + user type).
Both approaches scale better than assigning 2000+ manual “Cannot Read” rules.

[Renata82]

Thank you so much for the detailed answer! Especially the Dynamic User Criteria Script proposal (along with it's pros and cons) is extremely helpful as I was also thinking along the lines of advanced user criteria set up, but could not fully picture it in mind how to structure them.