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!

[Charlie Ward]

David,

I appreciate the feedback. Everything you have said makes sense…..in the IT world. We are using SN for facilities. Essentially we have various groups within Facilities, Maintenance which makes up electrical, plumbing, carpentry, painting, access controls, locks, etc., Housekeeping, Signage, Construction, Compliance, etc. We have a person for each department that is responsible for the content within their department. I didn't want to have to create all these different departments at Knowledge Base level because we are looking to implement SN for other areas of our business and wanted to keep Facitliies within one parent "folder". Also, many of these tradesmen are not as computer savvy and we need to lockdown multiple areas so content is not editable for anyone who has the knowledge role. This is something we have run into using SN for facilities as it is not as robust or specific enough for this industry. We have customized our workflows heavily because many OOTB items are geared towards IT…..someone who has an office with a desktop/laptop mouse and keyboard and not field workers. I was mainly inquiring if there other options that someone else has come up with for granular access control. If not, then I guess, we'll heavily customize using scripting or we'll have to follow the structure of breaking each of these departments up at Knowledge Base level to provide the granular support I'm looking for.

Thanks again

[Dave Smith1]

we'll have to follow the structure of breaking each of these departments up at Knowledge Base level to provide the granular support I'm looking for.

That would be my approach.

Also, many of these tradesmen are not as computer savvy and we need to lockdown multiple areas so content is not editable for anyone who has the knowledge role. 

Generally, they don't really need to be - they just need to be shown a simple process of:

• how do you search for/display content
• how do you edit/create new content

Note that Knowledge role is insufficient - really, it's about giving a contributor a specific domain of responsibility and letting them know they're managing "their own magazine" (KB). There are several magazines on the shelf, anyone can open them and read pages - but YOUR pages (KB articles) are the only ones you can write.

In my experience, I've found that people understand processes easier than technical products.   Fundamentally, being tech-savvy isn't really a benefit; being led through what's needed to acheive an objective is sufficient.

[gregg10 · Accepted solution]

I'm trying to find something very similar.   The challenge with ACL level is that OOB ACLs already exist.   That means the role is going to give permissions unless you deactivate that OOB ACL, which you don't want to do.

Business Rule Option

An option that would definitely work is to use a before Business Rule on update.   It would check the user and the Facility Department.   You can abort the action so the record does not save current.setAbortAction(true).   You'd probably want to show an info message as well.   You may want to do a display BR as well to show an Info message to the user that they will not be able to edit.

UI Policy

Write a script condition on a UI Policy for your Knowledge form.   It can make all of the fields read only.

[Charlie Ward]

Thanks for the info Gregg. This is what I was envisioning after watching a ServiceNow video about KB permissions which talked about using a Business Rule before query to do what I was looking for. It's just the matter of getting the script going.

[Charlie Ward]

Gregg,

Thank you for guiding me towards a solution. I just used the business rule as you suggested and it works like I need it to.