Best practices on creation of knowledge bases

[Daan Delva]

While going through the best practices documents for knowledge management, I couldn't find any recommendations on the best approach for handling knowledge bases. At the moment, we only have a knowledge base for the Service Desk (end users). However, more and more technical teams are asking if they can have their own knowledge bases. What is the recommended approach in this situation? Should each team have its own separate knowledge base, or is it better to have a single 'technical' knowledge base that covers everything?

Thanks in advance for sharing your feedback.

[GlideFather]

Hi @Daan Delva

the best practice is to match what suits the users the best... for some companies it will be a single KB for others it will be 14... I don't think there's any universal rule, of course the lower number the easier to maintain, but that goes along with the managers and owners of KB. Also translations... 

I would recommend to have as few KBs as possible, then the categories and subcategories are recommended not to be too many (but what is too many ,right?) and not going too depp, maximum 2 subcategory levels, not more.

But this is very individual for each organisation 😛 sorry for being so abstract...

[vaishali231]

Hey @Daan Delva 

In general, the recommended approach is to design knowledge bases around audience and purpose, not around individual teams.

For most organizations, it works best to keep the Service Desk or end user knowledge base separate, since that content is written in simple language and focused on self service, FAQs, and request guidance.

For technical teams, the usual best practice is to start with a single shared technical knowledge base rather than creating one per team. Within that technical knowledge base, you can use categories, metadata, and ownership to separate content by application, platform, or service. Access controls and roles can be used to make sure only the right teams can view or maintain their content.

This approach has a few key benefits.
It reduces duplication of articles across teams.
It makes cross team troubleshooting easier.
It simplifies governance, reporting, and content lifecycle management.
It keeps search results more consistent and useful.

Creating separate technical knowledge bases should generally be reserved for specific cases, such as regulatory or compliance requirements, strict data separation needs, or very large environments where teams operate independently with different governance models.

*************************************************************************************************************
If this response helps, please mark it as Accept as Solution and Helpful.
Doing so helps others in the community and encourages me to keep contributing.

Regards
Vaishali Singh

[M Iftikhar]

Hi @Daan Delva ,

This is a great question and a common crossroads for maturing Knowledge Management practices. While there isn't a "one-size-fits-all" answer, ServiceNow best practices generally suggest a hybrid approach based on Governance and Audience.

You need to decide between a single "Technical KB" and multiple "Team KBs."

1. When to use a Single "IT Internal" Knowledge Base

If your technical teams have similar requirements, a single unified Technical KB is often the most efficient.

• Pros: Lower administrative overhead (one set of categories, one owner), easier global search for technicians, and consistent formatting.

• Cons: It becomes difficult if the Network team requires review for their articles, while the Other team wants "Instant Publish."

• Best for: Small to mid-sized IT organizations where the "Internal IT" audience is essentially the same group of people.

2. When to Create Separate Knowledge Bases

You should consider a separate KB only when a team meets one of the following "Diversion Criteria":

• Different Security Requirements: If a team (e.g., Security/Infra) has sensitive data that only they should see, a separate KB with specific User Criteria is the safest way to silo that data.

• Different Approval Workflows: If the Database team requires a legal or compliance review before publishing, but other teams do not, a separate KB allows for a unique workflow.

3. The "Middle Ground" Recommendation (Best Practice)

Instead of a KB for every single team (which leads to "KB Sprawl"), group them by Domain or Function. For example:

1. IT Support (Public/End User): For your Service Portal.

2. IT Technical (Internal): A shared space for most IT teams (Desktop, Apps, Service Desk) to share internal fixes.

3. IT Operations (Sensitive): A restricted space for Infrastructure/Server/Security teams who handle sensitive configurations.

If my response helped, please mark it as the accepted solution so others can benefit as well.