Knowledge Base - Restrict Who Can Edit Articles at Article Level

[Charlie Ward]

We have finally started working on Knowledge Management. I have found an OOB issue with permission levels according to editing KB articles.

We have our KB broken up into our various KB categories including Security, Signage, Housekeeping, Maintenance and Construction. There are various articles within the categories that I would like to restrict editing. By default everyone can edit who has a role. I don't want to set the role permissions at the Knowledge Base level with Can Contribute, because I need further access control at the article level.

I have created a new choice list field on the knowledge article form called Facility Department (u_facility_department).

The goal is to allow only certain roles to edit certain KB articles.

For Example:

A maintenance manager can only edit articles related to maintenance which are categorized using the "Facility Department" choice list field, u_facility_department. A housekeeping manager can only edit housekeeping articles, a construction manager can only edit construction articles, etc.

I would have thought that whomever the Author of the article is would be the only person other than a knowledge_admin or admin, who could edit the knowledge article, but this isn't the case.

I'm not sure where to start or a script that might work, but where would the script go?

Thanks in advance!

[darius_koohmare]

Hi Charlie,

If you want to restrict read access, have you considered the 'can read' and 'cannot read' fields?

Select user criteria for an article

In addition, you can put a read ACL record on the kb_article table for fine tune access. This is where the script would go.

Access control rules

As for the write access, a write ACL record on the kb_article table is also a way to cause only a subset of access granted users to be able to edit the knowledge article record.

[Charlie Ward]

I'm not looking to see who can read and who can't. Anyone who has an itil role can read. I'm needing to control who can edit the article.

[darius_koohmare]

Have you tried setting an ACL for write access? In the conditions/script you can check the current user group/department against that department field.

[Dave Smith1]

I'm needing to control who can edit the article.

My understanding is that Can Read/Can Contribute controls are placed at KB level, not at category nor article level.

For what it's worth, SharePoint has controls at site level, library level and file level (analogous to KB, category and article) but best practise suggests not implementing them at file level, go for the "folder" instead (the library, the container it's in).   Similarly, if you find yourself implementing several library-level controls, you may as well add those libraries into a site then implement at site level.

Or, in summary: a system that provides this level of granularity also allows the possibility of creating high maintenance overheads.   I recommend to keep it simple and split security at site (KB) level.   Generally people aren't worried where content is located, they're more interested in how to get to it (the search mechanism).

SharePoint's approach is to permit anyone edit access, but restrict whom can publish the article - so anyone making changes creates a new draft version which is pending for review whilst readers are still looking at the unchanged (public) content, thus enforcing control not at content changes but at the release stage.   Unfortunately in ServiceNow's KBs, published articles can be amended whilst being published, meaning changes are immediately visible - there's no automatic move back to draft if post-publish changes happen.

So, where does this leave you?   My approach would be to have teams responsible for creating, reviewing and publishing content in a KB - let them decide if it's suitable or not.   Implementing article-level security feels like there's a trust issue between authors amending other created content, when really they should all be collaborating.

Or, as the Deli Llama said: don't build walls, build bridges. Encourage them to work collaboratively.