What This Table Is

The kb_knowledge_base table stores the top-level Knowledge Base definitions that serve as containers for all knowledge articles in ServiceNow. Each record represents a distinct knowledge base with its own language settings, ownership model, approval workflow, and access controls. Knowledge bases segment articles by business unit, geography, product line, or any organizational structure that requires separate content management.

Owned by the Knowledge module, this table controls the entire knowledge management process from article creation to retirement. The knowledge base defines which users can author articles, what approval workflow they follow, and how articles are categorized and searched. Each kb_knowledge article record must reference a knowledge base through its knowledge_base field.

This table does not extend any other table and serves as a parent configuration for the knowledge article ecosystem. The kb_knowledge table extends kb_knowledge_base through its reference relationship, while related tables like kb_category and kb_use_case also reference knowledge bases to establish their scope.

Most enterprises run 5-50 knowledge bases total, making this a low-volume table with excellent query performance. However, the knowledge bases control thousands to millions of knowledge articles, so your scripting against this table often determines the performance characteristics of knowledge searches and workflows across the entire platform.

When You'll Script Against This Table

You'll script against kb_knowledge_base primarily in Business Rules that manage knowledge base lifecycle, Script Includes that build knowledge search functionality, and Scheduled Jobs that synchronize knowledge bases with external content management systems. Knowledge Management admins with the knowledge_admin role can create and modify knowledge bases, while authors need knowledge_author role for read access.

Knowledge base scripting happens most often in Portal Widget Scripts for self-service knowledge searches, Transform Maps for content migration, and UI Actions for bulk knowledge operations. The Service Portal heavily queries this table to determine which knowledge bases are available to different user populations.

Common scripting patterns:

  • Filter available knowledge bases by user language preference
  • Check knowledge base active status before creating new articles
  • Query knowledge base owner to determine article approval workflow
  • Build dynamic choice lists of knowledge bases for article assignment
  • Synchronize knowledge base metadata with external content systems
  • Generate knowledge base usage reports and analytics
  • Validate user permissions for knowledge base access in portals

Table Gotchas

⚠️

The `disable_commenting` field defaults to false, meaning all knowledge bases allow comments by default. Many enterprises assume commenting is disabled and miss this security consideration.

  • The owner field references sys_user but can be empty - always null-check before accessing owner properties
⚠️

Knowledge base `language` field stores language codes like 'en' but doesn't validate against sys_language table. Invalid language codes break Portal knowledge searches silently.

  • Setting active to false doesn't hide existing articles from search - they remain discoverable until manually retired
  • The title field has no uniqueness constraint - multiple knowledge bases can have identical titles causing user confusion
⚠️

Deleting a knowledge base record doesn't cascade to its articles. The kb_knowledge records become orphaned and cause errors in knowledge workflows.

  • Query performance degrades significantly when joining knowledge bases to articles without proper indexing on kb_knowledge.knowledge_base
Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

No spam · Unsubscribe anytime

The primary relationship flows to the kb_knowledge table where every knowledge article references its parent knowledge base. This one-to-many relationship forms the core of knowledge management, with knowledge bases acting as containers that define language, workflow, and access policies for their articles. You'll frequently join these tables to filter articles by knowledge base properties like language or active status.

The sys_user table connects through the owner field to establish knowledge base ownership and approval authority. The kb_category table references knowledge bases to scope categories within specific knowledge domains. For Portal integrations, you'll commonly query sys_language alongside knowledge bases to match user language preferences with available content.

Advanced knowledge implementations often join to the sys_user_group table to implement group-based knowledge base access controls. Search and analytics workflows frequently aggregate across kb_social_qa_question and kb_feedback to measure knowledge base effectiveness and user engagement across different knowledge domains.