Flagging related articles across multiple knowledge base instances
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-15-2024 03:49 AM
Hoping someone can give me some guidance!
We have multiple knowledge base instances which are managed separately (and by different teams), but there are some articles that are similar - so when a change is made to an article in 1 instance, we are looking at the best way to ensure that any related article across other instances are also updated as we can't rely on the authors / owners to do this as often there are different people contributing to the different knowledge bases and articles.
Has anyone had any similar challenges and therefore able to offer any advice?
Thanks in advance!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-15-2024 09:09 AM
Hi Jo, I agree with Atul. As you mentioned in your original question, it becomes difficult to ensure content is updated across all KBs once you start to duplicate content. There are a few options you can consider.
Custom knowledge templates:
There are several benefits to custom knowledge templates. You can set required fields, they create consistency across your knowledge, and...you can show/hide fields based on "can read". Imagine one single article that would only show content based on the user's role. As an example, all of our articles contain a field named "Ticketing Details". This field is used by the help desk, but self-service users cannot see it. Here's what the template looks like in the back end:
Knowledge Ownership Groups
From ServiceNow documentation: For the ease of maintenance of knowledge articles, you can assign an ownership group to a knowledge article and shift the ownership of an article from a single person to a group. An ownership group consists of a group of members and a manager who are responsible for knowledge articles.
- Only ownership group members have contribute access to the article even if they don't have contribute access to the knowledge base of the article. They can edit, approve, publish, and retire the knowledge article with which they are associated.
- Users who aren't a member of the ownership group can't contribute to the article even if they have contribute access to the knowledge base of the article.
So how would they help you? If you created an ownership groups that consists of the teams that "own" the similar content, it could create a sense of shared responsibility and allows for editing across KBs.
Related Articles
You don't mention if you are mapping related articles, but if you aren't already doing that and you will continue to maintain multiple articles, I highly recommend doing so.
Automated Workflow
Another thought is to work with your ServiceNow team to build out a workflow for you based on the related article concept. Something like if an article is edited and it has associated related articles, flag the associated related articles to notify the author a change has been made. Not sure what the LOE is to get this done or if it's possible, but maybe a "simple" solution for now.
Break down barriers between the two teams
Regardless of the approach taken, at the end of the day you have to get the teams working together. Updating some of the content but not all of it will end up creating confusion and will lead to a
Kim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-15-2024 09:19 AM
Alternatively to creating a new field, would be to leverage knowledge blocks. You can then have one article with information available to everyone and then further troubleshooting steps that is in a knowledge block that has can read access set to your internal help desk. This would allow the end users to see only the information relevant to them but also allow the internal help desk see what steps the end user took and what additional steps they can take, all from one article to maintain.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-15-2024 10:21 AM
Yes! I forgot to include knowledge blocks! Thanks Dave!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-15-2024 10:57 AM
Thanks @Kim27 for in depth information.
If my response proves useful, please indicate its helpfulness by selecting " Accept as Solution" and " Helpful." This action benefits both the community and me.
Regards
Dr. Atul G. - Learn N Grow Together
ServiceNow Techno - Functional Trainer
LinkedIn: https://www.linkedin.com/in/dratulgrover
YouTube: https://www.youtube.com/@LearnNGrowTogetherwithAtulG
Topmate: https://topmate.io/atul_grover_lng [ Connect for 1-1 Session]
****************************************************************************************************************
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-15-2024 12:59 PM
We've structured our knowledge base similar to what AG is discussing but take it a step further, hopefully this is helpful for you.
We have several topics in our HR knowledge base that people at different levels should have access to. A very common scenario is a policy that has information relevant to ALL coworkers, additional information that leaders need to know, but would be inappropriate for non-leaders, and additional information appropriate to our HR Contact Center or other internal HR staff.
Previously we did house several different articles, but we've switched to using Knowledge Blocks. It's a little more maintenance to set up, but a very common structure is to craft a BA Article with the coworker-facing items as the main body of the article, but then add a "Leader Information" Knowledge Block and a "HR Information" knowledge block, each permissioned appropriately. In the end this truly does reduce maintenance overall, and makes it very easy for our team to find all the relevant information on a topic in only one article.