Knowledge Base Architecture, Best Practices and considerations

angelawheel
Tera Contributor

Hello, We are a hospital system that has been running our intranet based on established departmental hierarchy. As we look at the knowledge base structure. Is it better to go with a 1 internally public KB and many internally private? Or 
1 KB for every department. Even though some knowledge may be shared system wide. 

Thank you, 
ARW

7 REPLIES 7

Sounds good.  Let me know if you'd like to meet with me and I'll arrange a call with you and your account team.  You can contact me directly at eric.hemmer@servicenow.com.  You'll find lots of vidoes and other examples from customers who have done this on that Community page I shared with you earlier.  

erichemmer
ServiceNow Employee

Hi Angela - On this page you can sign up for future meetings and also watch many of the recordings.  We've been running this group since January of 2000 and there are over 2,100 members.  By registering for a meeting you will join our group.  Feel free to reach out to me directly if you'd like to show me what you've built for your intranet portal on ServiceNow.  I've helped hundreds of customers replace their old intranets with EC Pro.  I also lead our Best Employee Experience Contest and we're open for submissions right now.

MaryG
ServiceNow Employee

Adding some practical perspective here since this is a common decision point and the answer really depends on a few things you'll want to nail down first.

The "1 public + many private" model works well when you have a large body of content that's genuinely system-wide — think IT, facilities, HR policies everyone needs — and then department-specific content that only makes sense to that audience. The public KB becomes your front door and the private ones stay scoped. User Criteria handles who sees what on the article level, but having separate KBs gives you cleaner governance boundaries — different owners, different workflows, different review cadences without them stepping on each other.

The "1 KB per department" model mirrors your intranet hierarchy which feels familiar, but it can get unwieldy fast. You end up with a lot of KBs to maintain, duplicate content starts creeping in because nobody knows what's in another department's KB, and if you ever want AI Search or Now Assist surfacing content across the org, fragmentation works against you.

For a hospital system, I'd lean toward a middle path: a small number of KBs organized around audience and governance, not org chart. Something like one for enterprise/system-wide content, one for IT/technology, one for HR/people services, and then evaluate clinical or department-specific ones only if the content truly requires separate ownership and workflow. Keep the number low and use categories + User Criteria to handle the scoping within each KB.

The question to pressure-test any decision: who owns this content, who approves it, and who should be able to find it? If the answers are different enough, that's a KB boundary. If it's just "different department," that's a category.