ServiceNow CMDB Basics

The Configuration Management Database (CMDB) is ServiceNow's inventory of every IT asset and the relationships between them. Every server, laptop, application, network device, and cloud resource a company owns or manages becomes a record in the CMDB. When something goes wrong, the CMDB shows not just what failed, but what else depends on it — making impact analysis fast and accurate.

What the CMDB Stores

The CMDB stores Configuration Items (CIs). A CI is any component that needs to be tracked to deliver IT services. CIs include:

  • Hardware: Servers, laptops, desktops, network switches, routers, printers
  • Software: Applications, operating systems, databases, middleware
  • Cloud resources: Virtual machines, cloud storage buckets, load balancers
  • Services: Email service, payroll application, customer portal
  • People: Some implementations track contractors and vendors as CIs

CI Classes: The CMDB Table Structure

The CMDB uses a class hierarchy to organize CIs. Every CI class is a table that extends a parent class. The base class for all CIs is cmdb_ci. Specialized classes inherit its fields and add their own.

cmdb_ci (Base CI — all CIs share these fields)
  ├── cmdb_ci_hardware (physical devices)
  │     ├── cmdb_ci_computer (computers)
  │     │     ├── cmdb_ci_server (servers)
  │     │     └── cmdb_ci_pc (workstations)
  │     └── cmdb_ci_netgear (network gear)
  │           ├── cmdb_ci_router
  │           └── cmdb_ci_switch
  ├── cmdb_ci_appl (applications)
  │     ├── cmdb_ci_db_instance (databases)
  │     └── cmdb_ci_web_server
  └── cmdb_ci_service (IT services)

CI Relationships

The real power of the CMDB is relationships — connections that show how CIs depend on each other. Every relationship has a type and a direction.

Relationship Example: Email Service depends on multiple CIs

[Email Service CI]
       │
       ├── "Runs on" → [Email Application Server CI]
       │                        │
       │                        ├── "Hosted on" → [Physical Server CI]
       │                        │                         │
       │                        │                         └── "Located in" → [Data Center CI]
       │                        │
       │                        └── "Uses" → [Email Database CI]
       │
       └── "Depends on" → [Network Switch CI]

This map means: if the Physical Server goes down, the CMDB instantly shows that the Email Application Server, the Email Service, and all users of that service are affected. No one needs to manually trace the impact — the CMDB relationship map answers the question in seconds.

The CI Dependency Map

ServiceNow's CI Dependency View renders a visual map of a CI and all its relationships. Opening a server CI and clicking Dependency View shows a graphical network diagram — every CI connected to that server, the type of relationship, and the direction of dependency. Incident managers use this during an outage to understand scope immediately.

Key Fields on a CI Record

  • Name: The CI's descriptive name (e.g., "PROD-DB-01")
  • Class: What type of CI it is (Server, Application, etc.)
  • Status: Operational, Non-operational, Retired
  • Environment: Production, Development, Test, Staging
  • Managed by: The team responsible for this CI
  • Supported by: The support group that handles incidents for this CI
  • IP Address: (For network-connected hardware)
  • Assigned to: The individual owner or responsible person

Linking CIs to Incidents and Changes

When an agent creates an incident for a broken server, they link the server's CI record to the incident in the "Affected CIs" field. This linkage enables impact reporting — how many incidents affected this CI in the last 90 days? Which CIs generate the most incidents? These insights guide where to focus infrastructure investment.

Changes also link to CIs. A planned server upgrade links to the server's CI. The change calendar then shows that the server has a change scheduled — preventing other teams from planning changes to the same CI at the same time.

CMDB Completeness and Health

A CMDB is only useful if its data is accurate and current. ServiceNow provides a CMDB Health Dashboard that scores the CMDB on completeness (all required fields populated), compliance (CIs match their class requirements), and correctness (relationship data is logically consistent). Organizations track this score and set improvement targets — aiming for a high-health CMDB that teams trust as a reliable source of truth.

Manual vs. Automated CI Population

Small organizations populate the CMDB manually — administrators create CI records one by one. Large organizations use ServiceNow Discovery (covered in the next topic) to automatically scan the network and create or update CI records. Automated population keeps the CMDB current without requiring ongoing manual data entry.

Leave a Comment

Your email address will not be published. Required fields are marked *