cmdb_ci Table — ServiceNow Reference

Table Reference/cmdb_ci

The cmdb_ci table is the foundation of ServiceNow's Configuration Management Database, storing all Configuration Items across your IT infrastructure. Owned by the CMDB module, it's extended by over 100 specialized CI classes. Never query this table directly in production — always target the specific CI class you need or use the cmdb table for cross-class queries.

What This Table Is

The cmdb_ci table serves as the abstract base for all Configuration Items in ServiceNow's CMDB. It defines the core attributes shared by every CI — identification, operational state, lifecycle tracking, and relationship capabilities. This table establishes the foundational structure that enables ServiceNow to model your entire IT infrastructure as interconnected configuration items.

Owned by the Configuration Management Database (CMDB) module, this table supports the complete ITIL configuration management process — from CI discovery and registration through change impact analysis and relationship mapping. The CMDB process relies on accurate CI data to enable change management, incident resolution, and service impact analysis across your IT infrastructure.

The cmdb_ci table extends the cmdb table and is extended by over 100 specialized CI classes including cmdb_ci_server, cmdb_ci_appl, cmdb_ci_database, and cmdb_ci_service. Each child class inherits the base CI attributes while adding class-specific fields relevant to that configuration item type. This inheritance hierarchy enables both specialized CI management and unified cross-infrastructure queries.

In large enterprise implementations, the CMDB typically contains 50,000-500,000+ CIs with millions of relationship records. The cmdb_ci table itself may hold 10,000-50,000 records representing CIs that don't fit specialized classes. Query performance depends heavily on proper indexing and filtering by sys_class_name to avoid full table scans across the entire CI hierarchy.

When You'll Script Against This Table

You'll primarily script against cmdb_ci in Business Rules that fire on CI lifecycle events, Script Includes handling cross-CI-class operations, and Scheduled Jobs performing bulk CI maintenance. Discovery and Integration Hub flows frequently update CI records through server-side scripts. Background Scripts are common for data cleanup and mass CI updates during CMDB health initiatives.

The itil role provides basic CMDB read access, while cmdb_admin enables full CI management. The discovery_admin role is required for automated CI creation and updates. ACL enforcement varies by CI class, with some sensitive CIs requiring elevated permissions even for read access.

Common scripting patterns:

Bulk CI state transitions during maintenance windows or decommissioning projects
Cross-reference validation between CIs and other ITSM tables (incidents, changes, requests)
Assignment group propagation from CIs to related incidents and changes
CI attribute synchronization from external data sources and discovery tools
CMDB health scoring and duplicate CI identification through automated analysis
Service impact analysis by traversing CI relationships during incident management
Automated CI lifecycle management based on deployment status and usage metrics

Table Gotchas

⚠️

Never query cmdb_ci directly in production without filtering by sys_class_name. Without this filter, you'll scan the entire CI inheritance hierarchy causing severe performance issues.

⚠️

The operational_status field uses integer values, not choice labels. Use getDisplayValue() or check the choice list definition before hardcoding status comparisons.

The install_status field represents the CI's lifecycle stage while operational_status represents its current operational state — many developers confuse these two concepts
CI relationships are stored in separate tables (cmdb_rel_ci), not as reference fields on the CI record itself — use relationship APIs for traversal

⚠️

The support_group and assignment_group fields don't automatically inherit from parent CIs. You must implement Business Rules if you want group inheritance behavior.

Discovery processes can create duplicate CIs if identification rules aren't properly configured — always implement CI reconciliation logic in discovery Business Rules
Queries joining CIs with incidents or changes should use indexed fields like sys_id rather than name to avoid performance bottlenecks

⚠️

The company field may be null for CIs discovered automatically. Always null-check before using company-based filtering or reporting.

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.

The cmdb_ci table extends the cmdb table, which provides the foundational structure for all configuration management objects. The cmdb table contains core identification fields and serves as the root for the entire CMDB class hierarchy. When building reports or queries that span multiple CI types, you often query the cmdb table directly to get a unified view.

The cmdb_rel_ci table stores all relationships between configuration items and is constantly queried alongside CI tables for impact analysis and dependency mapping. The task table and its children (incident, change_request, sc_request) frequently reference CIs through cmdb_ci fields, enabling service impact tracking and automated assignment based on CI ownership.

User and group tables (sys_user, sys_user_group) are joined constantly for CI ownership, support group assignments, and approval workflows. The core_company table provides organizational context for multi-tenant CMDB implementations, while cmn_location enables geographic and facility-based CI organization and reporting.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
name	string	Name	Display name of the CI. Not guaranteed to be unique across CI classes — use sys_id for reliable identification.
operational_status	integer	Operational Status	Current operational state (1=Operational, 2=Non-Operational, etc.). Stores integer values, not choice labels.
install_status	integer	Install Status	Lifecycle stage of the CI (1=Installed, 6=Retired, etc.). Often confused with operational_status but represents different concepts.
sys_class_name	string	Class	The exact table name of the CI's class (cmdb_ci_server, cmdb_ci_appl, etc.). Essential for performance when querying CI hierarchies.
support_group	reference	Support Group	Group responsible for supporting this CI. References sys_user_group but doesn't automatically inherit from parent CIs.
assignment_group	reference	Assignment Group	Group assigned to manage this CI. Separate from support_group and used for task assignment propagation.
owned_by	reference	Owned by	Business owner of the CI. References sys_user and affects approval routing for CI-related changes.
managed_by	reference	Managed by	Technical manager responsible for the CI. Often different from owned_by and used for operational notifications.
company	reference	Company	Company that owns the CI. May be null for discovered CIs — always null-check before using in filters.
location	reference	Location	Physical or logical location of the CI. References cmn_location and enables geographic reporting.
environment	string	Environment	Deployment environment (Production, Test, Development). Critical for change impact analysis and approval workflows.
asset_tag	string	Asset Tag	Physical asset identifier linking CI to asset management records. Used for hardware lifecycle tracking.
serial_number	string	Serial Number	Manufacturer serial number. Key field for hardware CI identification and warranty tracking.
model_id	reference	Model	References cmdb_model table for hardware specifications. Essential for capacity planning and compatibility checks.
manufacturer	reference	Manufacturer	References core_company for the CI manufacturer. Used in vendor management and support routing.
discovery_source	string	Discovery Source	How the CI was discovered (ServiceNow Discovery, Import, Manual). Affects data quality scoring and update policies.
first_discovered	glide_date_time	First Discovered	When CI was first found by discovery. Read-only field used for CMDB age analysis and lifecycle reporting.
last_discovered	glide_date_time	Last Discovered	Most recent discovery timestamp. Used to identify stale CIs that may need retirement.
attributes	string	Attributes	JSON field storing discovery attributes. Contains key-value pairs from discovery probes — parse carefully to avoid errors.

Common Queries

Get all active CIs in operational status

// Get CIs that are installed and operational
var gr = new GlideRecord('cmdb_ci');
gr.addQuery('install_status', 1); // Installed
gr.addQuery('operational_status', 1); // Operational
// Always filter by class to avoid full hierarchy scan
gr.addQuery('sys_class_name', 'cmdb_ci');
gr.query();

while (gr.next()) {
    gs.info('CI: ' + gr.name + ' (Class: ' + gr.sys_class_name + ')');
}

Find CIs by support group and environment for change planning

// Get production CIs managed by specific group
var gr = new GlideRecord('cmdb_ci');
gr.addQuery('support_group.name', 'Database Team');
gr.addQuery('environment', 'Production');
gr.addQuery('install_status', 1); // Only installed CIs
gr.orderBy('name');
gr.query();

var ciList = [];
while (gr.next()) {
    ciList.push({
        name: gr.name.toString(),
        id: gr.sys_id.toString()
    });
}
gs.info('Found ' + ciList.length + ' production CIs');

Get CIs owned by users in specific department for compliance reporting

// Find CIs owned by Finance department users
var gr = new GlideRecord('cmdb_ci');
gr.addJoinQuery('sys_user', 'owned_by', 'sys_id')
  .addQuery('department.name', 'Finance');
gr.addQuery('install_status', '!=', 7); // Exclude retired
gr.query();

var results = [];
while (gr.next()) {
    var owner = gr.owned_by.getRefRecord();
    results.push({
        ci: gr.name.toString(),
        owner: owner.name.toString(),
        status: gr.operational_status.getDisplayValue()
    });
}

Count CIs by operational status for dashboard metrics

// Aggregate CI counts by operational status
var ga = new GlideAggregate('cmdb_ci');
ga.addQuery('sys_class_name', 'cmdb_ci'); // Only base class
ga.addQuery('install_status', '!=', 7); // Exclude retired
ga.addAggregate('COUNT');
ga.groupBy('operational_status');
ga.query();

var statusCounts = {};
while (ga.next()) {
    var status = ga.operational_status.getDisplayValue();
    var count = ga.getAggregate('COUNT');
    statusCounts[status] = parseInt(count);
    gs.info(status + ': ' + count);
}

Wrong way vs right way: Querying across CI hierarchy

// WRONG: This scans entire CI inheritance hierarchy
// var gr = new GlideRecord('cmdb_ci');
// gr.addQuery('name', 'CONTAINS', 'web');
// gr.query(); // Performance disaster!

// RIGHT: Filter by specific CI class first
var gr = new GlideRecord('cmdb_ci_server');
gr.addQuery('name', 'CONTAINS', 'web');
gr.addQuery('install_status', 1);
gr.query();

// Or use cmdb table for cross-class queries with proper indexing
var grCmdb = new GlideRecord('cmdb');
grCmdb.addQuery('name', 'CONTAINS', 'web');
grCmdb.query(); // Better performance with proper indexes

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue

cmdb_ci