Knowledge - Version Control

[iball]

Hi All,

I'm currently in the process of scoping the Knowledge module for our deployment of ServiceNow (Calgary release).

One of the business requirements is that there is version control for the Knowledge articles, similar to a Wiki.   Is this supported in ServiceNow?

I did come across the Managed Document and Knowledge Document plugins, however this seems to be more related to uploading actual documents to ServiceNow.   We want version control around the actual Knowledge article itself.

A thought I did have if it isn't supported would be to make use of the Audit table, Updates field and also add a "Major Version" field.   The Audit table could capture changes to the article description (and other fields), the Updates field would be the revision number and is automatically updated.   The Major Version would be automatically updated each time the document is published.

Any thoughts or advise would be much appreciated.

Thanks in advance,

Ian

[Jamie_douglas · Accepted solution]

Hey,

So you want to manage the life cycle of knowledge articles right?

If this is so, how do you want to manage them?

My Experience with knowledge:

Retiring articles:

Create a script that will retire your article after a specified period, maybe 6 months maybe 18 months, whatever your requirements are.

Day to day management:

I have used the KCS methodology to manage the life-cycle of an article.

Quick run down on roles we used:

KCS1 - itil user - able to search articles

KCS2 - itil user with some knowledge training - can edit/update articles

KCS3 - Power knowledge user - able to publish articles so that end users (non itil users) can see articles. This needs to be dished out lightly to people with good grammar and who can explain techy stuff to non techy people.

We also used statuses for specific purposes such as:

approved - KCS1 can see and search

publish - KCS1 and end users can see and search

retire - once an article reached its expiry date it would change from draft or publish to retire which is then view able by KCS2 to either decommission or update and set to approved or published again.

Another important item:

Marking an incident or request as "knowledge required" created a knowledge submission and assigned to KCS2 users to create and approve. These are then traceable KPI's for those staff and you should build up a solid knowledge base pretty quickly.

The information above is really handy as out of box the only status to use if you want ITIL users to see the articles is Published which means end users can see them too.

By creating a few roles i.e KCS1, 2 & 3 and changing a few statuses you can "approve" items to be viewed by ITIL users and then change status to "Publish"   for those articles that you want end users to see.

One tip I would give you that you should take on board.. A lot of companies want to push end users onto a portal for self help so that they can reduce their inbound calls and empower end users to help themselves.. Providing end users with GOOD knowledge will aid in reaching these goals so I would say you want to make sure you get a good knowledge process in place.

I have a few short documents on KCS if you would like to read them, might give you some insight. PM me if you would like them!

Hope that gives you some ideas!

[iball]

Hi Jamie,

Thanks for your reply.   That's very helpful.

The only other thing I needed was version control.   So we can track edits to the articles and increment a version number for each edit?   That seems to be one of the things the business is most concerned about with this - I assume so it fits in with the document management process   we currently use (MS Sharepoint).   Does ServiceNow support something like that?

Cheers,

Ian

[danielbilling]

Hi,

Have a look at KM submission workflow : https://wiki.servicenow.com/index.php?title=Knowledge_Workflow

if you go with a KCS approach as Jamie pointed out and use submission to update your article. I believe it would be a minor thing to add a version numbering to that article from there

/Daniel

[Jamie_douglas]

unfortunately we didn't have the managed document plugin, i think we were on Aspen!

Anyways, I like rfedoruk's comments. We locked down the KBA by status and we used our own work instructions to republish a retired record which kept the same KBA number and link etc. We also embeded record producers into knowledge articles which was cool.

Its good to know there is already a pre-built solution from crossfuze now! We didnt have the luxury of purchasing a pre built solution but then if we had weighed up the costs it probably would have been worth purchasing rather than developing!