Known Error Database best practices for MSP

[Lowell Coleman]

Hello,

I'm looking for best practices around setting up Known Error Database as an MSP.

OOTB, there is a "known error" Knowledge Base in the 'global' domain.

Issue: When a user from client domain A creates a Known Error article, the article will be created under the 'global' domain OOTB making it visible to all. The article inherits visibility from the 'global' knowledge base.

As an MSP setting users from various clients as a 'manager' to facilitate Known Error knowledge article approvals related to a 'global' knowledge base won't work. 

Do you create client-specific known error databases on a case-by-case basis per domain (client)?

[Nicholas Bentle]

You're correct that OOTB, known error articles default to the global domain Knowledge Base, inheriting broad visibility. Assigning client users as managers to the global Knowledge Base isn’t ideal for isolation.

The recommended/best practice approach is to use “Client-Specific Knowledge Bases” per Domain. ServiceNow’s domain separation handles Knowledge perfectly—articles stay locked to each client domain while Service Provider admins toggle domains to review or publish. This is considered the cleanest long-term MSP setup.

That said, like with many ServiceNow solutions, there are always alternative approaches. Another you could explore is a “Service Provider Manager Review” model. In this approach, no client managers are needed, you let client’s create Draft articles in the global Knowledge Base (give them enough to create but not publish). Your Service Provider Knowledge Managers then review and publish everything centrally. Knowledge Base roles lock clients to draft-only access, and could be supported by a simple approval workflow and UI actions which rout to your Service Provider Knowledge Managers. I’ve provided some quick pros and cons for both approaches below:

Client-Specific Knowledge Bases per Domain

PROS: True data isolation, can scales with client growth, clients self-manage within their domain, Service Provider oversight via domain paths.

CONS: Requires Domain Separation to be activated, initial Knowledge Base setup per client, requires a UI action tweak for the "Create KE" button.

Personal view: While I understand and agree that this is the best-practice or recommended approach, I do feel it somewhat defeats the purpose of maintaining a global domain and a single Knowledge Base accessible across all domains. In many cases, the same solution could end up being duplicated across clients, especially when the information doesn’t involve sensitive or client-specific data (such as PII or IP details). There’s value in leveraging a shared Knowledge Base when full isolation isn’t strictly necessary.

Service Provider Manager Review

PROS: Super simple start, total Service Provider publishing control, mostly OOTB.

CONS: The Service Provider becomes a bottleneck (publish delays hurt deflection), draft visibility risks if ACLs slip, doesn’t scale well.

Personal view: From my perspective, while this approach aligns with having a single global Knowledge Base and the listed pros and cons are valid, I’m generally hesitant to introduce even small customisations. Though this one isn’t major, it goes against my usual principle of keeping ServiceNow implementations as close to out‑of‑the‑box as possible.

I hope this is useful for you and good luck with which approach you look to take.