Changes to OOTB behavior for KBs and Versioning

[Quan Truong]

I'm a manager of an Epic specific KB library. We've been using KBs to house our tip sheets for a couple years now. We've run into the issues outlined below. We requested changes but our ServiceNow team is reluctant to move away from the OOTB functionality. Has anyone else run into these types of issues? If so, how did you solve them?

Edit: 

Here's a bit more context on our setup.

We already have a Epic specific KB Library. The library is set up so that all ServiceNow users can read any articles. But only members of the Epic team can add or edit articles. When I say "all users" in the "Requested Fix" column, I meant all users on the Epic team. Not all ServiceNow users.

The first request to expand retiring KBs could be just to expand to the members of the owning team. We figured just expand it out to the entire Epic team because we're not concerned with analysts inappropriately retiring articles.

The reason for wanting to expand the edit ability to all editing users in the library is because we have several articles that span different Epic teams. We have articles for upgrades that are user specific but span different pieces of functionality with different owning teams. So our process right now is for users of the "owning" team to update the article with information sent to them from the other contributing teams. This creates an unnecessary middle man who is updating the article with information they aren't the expert on.

The last issue is another variation of the above where we can have multiple members of the same team working on a KB article for our users. 1 member may be the expert on one part of the article while another member is the expert on another. The workflow now is for member #1 to checkout, edit, request approval for publishing, then get the article published. Our approval workflow is set up so that a member of the Epic team who isn't the author must approve the changes. Then member #2 has to do the same. It would be much better if we could have a "check-in" function which would save the changes but then allow others to make edits. As is, the process takes longer and it's possible for users to view half-edited KAs.

[Greg Yuh]

Quan,

The list you have under "Requested Fix" is not a good idea for several reasons: Everyone should not be able to retire KBs nor edit KBs they are not the SMEs on.  Due to the nature of KBs, I am also not sure why you would want multiple people updating the document at the same time.

I think you can make a case for allowing all KB managers to retire/update any KB articles but also allow Authors to retire/update their KBs (since some KBs will be written by SMEs who are not always a member of the KB Managers group).  I would recommend using the OOTB and adopting your processes to match.

Have you thought of creating an "EPIC" specific kb_knowledge_base where you can be the owner and have all the EPIC support team be members of the "Manager" group?

[Punahele Tanne1]

Completely agree with Greg.  The post reads like a severe overcorrection because some groups are not taking responsibility for the content they have created.  Opening up editing so that those interested and motivated to maintain the Knowledge Base by dissolving structured responsibility does not solve what might be the true problem.

I also like the Epic KB with Assignment Group managers as well, perhaps expanding to add team leads or senior-level techs for delegation of KA review and management.

I'm not sure if this is out of the box, but KAs in my instance allow the Assignment Group manager and Assignment Group members to manage their articles.  In support of that, visibility was greatly increased by adding a KPI/Dashboard tab to show about-to-expire and expired articles to group members, group managers, and managers of the managers.

In support of expiring articles being re-upped, a UI action button was created named "Revalidate" which simply adds one year to the Valid To date.  It has the same restrictions as the "Initiate Adhoc" button, so it can only be done by the Author, the Assignment Group members and the Assignment Group manager.

And in support of all of the above, a scheduled job was built that evaluates the Valid To of the knowledge table every morning and sends an email to the Assignment Group and Assignment Group manager of any expiring articles within 28 days, the frequency of the email notifications increases on a an increasing curve the closer it gets to the articles Valid To date.  At the present, 7 notifications go out before the articles expires, the body of which include instruction to click the link in the email to get to the KA, reviewing the content of the article, and then click the "Revalidate" or "Retire" buttons.  NOTE: apparently is functionality since Paris that does something similiar on the first of the month.  Knowledge article validity (servicenow.com)

[Alan Prochaska]

More agreement, but a few questions.

Quan,

How many articles?   How many authors/editors?

Generally speaking, opening up permissions to "anyone can do anything to anything" leads away from a well-managed system, even for the most conscientious groups.  

If the group members need to be able to act quickly and move on, create the ability for them to flag quickly in a comment (eg) "#Retire" or "#UpdateNeeded".  Those can be triggers to the article owners for action, and the accountability for the article remains intact.

Alan

[Quan Truong]

Additional context added in the original question