Examples of best practice for creating multiple knowledge bases

hhr
Kilo Contributor

Hi, I am looking for some best practice examples on how to set up knowledge bases in a global, multi function company. Are there any published best practice that I can refer to.

1 ACCEPTED SOLUTION

Dave Smith1
ServiceNow Employee
ServiceNow Employee

Each KB can have people nominated as authors (Can Contribute) or viewers (Can Read) in User Criteria, but these controls are imposed on a per-KB basis, rather than per-category or per-article. In other words, a contributor in one KB can edit any articles, including those not written by them.   Don't forget that there's an audit trail showing who has been changing it, and when, so it's possible to identify authors in conflict.



From a governance point of view, there's a Publishing Approval workflow that means authored articles require one of the KB's nominated Knowledge Managers to approve an article for publication before it's viewable by readers, but this doesn't prevent an author from amending an article once it's published - you may want to consider a BR that flicks the article back to "Draft" if the last edit date is later than the approved date.



In terms of best practise: treat KBs as libraries, consider the core purpose of each library and decide what criteria makes readers/writers accordingly. It is easier to have several KBs with access set at the library door than to leave the doors open and attempt to secure individual rooms (categories) or books (articles).


View solution in original post

12 REPLIES 12

Hello,

We have a request to restrict access to a particular KB for all users with 'admin' role, specifically on the Service Portal. 

Any user criteria defined for users/groups with non-admin role works well, but if the user has 'admin' role, the system bypasses restriction and KB and related articles can be viewed.

The  functions for canRead and canContribute with script include have code to bypass restriction if user has admin role.  Commenting that code does not produce the desired restriction.

While this type of request is unusual, do you have any suggestions?

We are on Kingston version with v3 Knowledge.

Thank you,

Rupa

 

 

Dave Smith1
ServiceNow Employee
ServiceNow Employee

"We have a request to restrict access to a particular KB for all users with 'admin' role, specifically on the Service Portal." -when you say restrict access do you mean access is restricted only to admins, or that admins are prevented from accessing it?

If it's the latter, then there's your issue- the admin role isn't restricted; most ACLs permit admin bypass solely for support and operational purposes.

If you have many users with this role and still need to secure content from them, you possibly have a poorly-designed security model.

Is there an out of the box rule which can restrict an admin from viewing all the articles?

How can a normal admin can view HR or Security Related Knowledge articles. That's poorly design security model of ServiceNow, where knowledge is not scoped.


Please mark this response as correct or helpful if it assisted you with your question.

"How can a normal admin can view HR or Security Related Knowledge articles. That's poorly design security model of ServiceNow, where knowledge is not scoped."

.. only if your security policy mandates that a "normal admin" isn't to view HR or Security Related Knowledge articles.  I believe there's some changes in HR in which the ACLs do not have "Admin Override" ticked, meaning that specific content areas are unavailable to those holding the admin role - it may be worth checking into those.

But I agree, all sections of the platform should really be scoped to delegate management functions out.

I am looking for ServiceNow guidance in making a decision:

-  one knowledge base with heavy customization (governance, workflow, audience, categories, permissions, etc) -or-

-  separate knowledge base

someone stated "ServiceNow recommends one knowledge base for all of IT" but has no document to support that statement.  Am not seeing the reason for this recommendation.  Without wanting to have 30 KB's, am thinking if the governance, audience, workflow are different ... why heavily customize?

what would be the criteria to decide this should be a separate knowledge base ... thank you if someone  can help