Knowledge Base Best Practice

[nickm5816667392]

Hey all, we're about a year into our ServiceNow journey and are working to get our Knowledge into a good place.

The partner that worked with us to set up ITSM designed it so that there are two knowledge bases: IT and Public. Regardless of which one you use, the approval goes to two people.

We want to redesign this so that KBs written by the server team get approved by the server lead. KBs written by the networking team should be approved by the networking lead, etc. We still want to maintain just two audiences: either IT or public (the entire company).

To accomplish this, our current partner suggested that we have a separate knowledge base for each of the eight IT departments. This sounded like a good idea, but has had some undesirable effects on the employee center side.

Our employee center has a knowledge button that allows staff to peruse all articles published for them. In the top left there is a Knowledge Bases dropdown that allows them to browse through various knowledge bases. This is overkill, end users don't care which team published the article. There's also a Categories section. We're now seeing duplicate categories in this list. For example, we have two Zoom categories due to one team writing a Zoom KB in their knowledge base and then a separate team writing a separate article in their knowledge base. We're a small enough IT group that we're going to see overlaps like this with some applications.

I want to get this right and now is the time as we only have 100 or so KBs published.

I'd love to hear what everyone else is doing. For what it's worth, we're an IT team of 25 with about 1,200 employees. Thank you!

[vaishali231 · Accepted solution]

hey @nickm5816667392 

Keep Knowledge Bases aligned to audience, and manage approvals using ownership and dynamic workflows.

 Approach

1. Keep Only Two Knowledge Bases

• IT (internal users)
• Public (all employees)

Knowledge Bases should represent who can see the content, not who owns or approves it.

2. Use Ownership Group for Articles

Leverage the Ownership group (or Knowledge group) field on the article.

Examples:

• Server articles - Server Support Group
• Network articles - Network Support Group

This allows you to logically separate content without creating multiple KBs.

3. Implement Dynamic Approval Logic

Instead of static approvers, configure approvals based on the article’s ownership group.

 Recommended Approach (Flow Designer)

Trigger: When article moves to “Review”

Logic:

• Read Ownership Group
• Identify approver (e.g., Group Manager or mapped user)
• Send approval request

 Scalable Option

Create a mapping table:

• Group - Approver

This avoids hardcoding logic and supports future growth.

4. Standardize Categories (Fix Duplicate Issue)

Duplicate categories (e.g., multiple “Zoom”) occur because categories are tied to each KB.

Best practice:

Define a common category structure

Ensure both KBs follow the same hierarchy

Example:

• Applications - Zoom
• Applications - VPN
• Hardware - Laptop

Also, assign a Knowledge Manager role to govern category creation.

5. Improve Employee Center Experience

From an end-user perspective:

Users should search or browse categories

They should not need to choose a Knowledge Base

Suggestions:

Minimize or hide KB filter (if feasible)

Focus on:

• Search
• Categories
• Featured content

*************************************************************************************************************************************

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