ServiceNow CMDB and CSDM

ServiceNow is a widely used IT service management platform, and its CMDB is where many organizations hold their record of what they run. CSDM is the model ServiceNow publishes for how that record should be structured.

What is the ServiceNow CMDB?

The ServiceNow CMDB is a set of tables inside a ServiceNow instance that store configuration items (CIs) and the relationships between them. Every CI is a row in the base table, cmdb_ci, or in one of the hundreds of tables that extend it. Relationships live in a separate table, cmdb_rel_ci, where each row links a parent CI to a child CI with a type such as “Runs on::Runs” or “Depends on::Used by”.

Because it sits inside the platform, the CMDB is referenced by the other ServiceNow applications: an incident has a field for the affected CI, a change request lists the CIs it touches and a vulnerability record points at the CI it was found on. See CMDB for the general concept.

Assets live in separate tables linked to their CIs, the platform’s version of the IT asset management split.

How are CI classes organized?

CI classes form a hierarchy, and each class is a table that extends its parent.

• cmdb_ci is the base, with the fields every CI has: name, class, owner, support group, operational status, location.
• cmdb_ci_hardware extends it for physical and virtual devices, and cmdb_ci_computer extends that.
• cmdb_ci_server extends computer, and operating system classes such as cmdb_ci_linux_server and cmdb_ci_win_server extend server.
• cmdb_ci_appl covers running software such as a database instance, with child classes per product.
• cmdb_ci_service and its children hold services, which CSDM splits into business, technical and application services.

Custom classes extend an existing one, and choosing the right parent matters because the identification rules that decide whether a discovered server matches an existing record are defined per class and inherited.

What is CSDM and why does it exist?

The Common Service Data Model (CSDM) is ServiceNow’s published standard for which CMDB tables to use for which purpose, how to relate them and what to call them. It is documentation rather than an application: the tables already exist, and CSDM says how to use them consistently.

It exists because the platform leaves a lot of choices open. Before CSDM, one organization recorded its applications as business services, another as application CIs and a third in a custom class, and each then found that ServiceNow applications such as event management and service portfolio management expected the data somewhere else. CSDM gives every ServiceNow application the same answer to “where are the business applications” and “which CIs make up this service”. Later versions add tables and domains, and the five below are the core.

What are the CSDM domains?

The diagram at the top shows the domains as columns, with the tables most implementations start from.

Domain	What it holds	Key tables
Foundation	Reference data every other domain points at	core_company, cmn_location, sys_user_group, sys_user, business_unit, cmn_department
Design	How the business thinks about what it does	cmdb_ci_business_capability, cmdb_ci_business_app, cmdb_ci_information_object, cmdb_ci_business_process
Build	The development lifecycle	sdlc_component, which links code repositories and pipelines to a business application
Manage technical services	What IT runs	cmdb_ci_service_technical, service_offering, cmdb_ci_service_auto (application service) and the CIs beneath them
Sell/Consume	What the business and its customers request and use	cmdb_ci_service_business and its service offerings

The relationships are the point. A business application is the logical thing the business recognizes (“the CRM”), and it consumes one or more application services, which are the deployed instances (CRM production, CRM test). Each application service contains the servers, databases and application CIs that make it up, which is what service mapping produces. A business service offering depends on application services, so an outage surfaces as an impact on what people consume. The Design domain is where a business capability map lives and where enterprise architecture teams do most of their work, and its business applications are what application portfolio management scores and application rationalization decides on.

How does data get into the ServiceNow CMDB?

• Discovery. ServiceNow Discovery scans IP ranges from a MID Server, logs in to hosts with stored credentials and creates or updates CIs for the servers, devices, software and processes it finds.
• Service Mapping. Top-down discovery that starts from an entry point such as a URL, follows the connections outward and stores the result as an application service with its CIs and relationships. It is how application dependency mapping results land in the CMDB.
• Integrations. Service Graph Connectors bring in data from cloud providers, monitoring, endpoint management and other tools already shaped for CSDM.
• Manual entry. Business applications, capabilities and service offerings are usually created by people, because no scanner knows what the business calls something.

Everything that arrives passes through the Identification and Reconciliation Engine (IRE), which applies per-class identification rules to decide whether a record is new or an update, and reconciliation rules to decide which source is trusted for each attribute. The CMDB Health dashboard then scores the result for completeness, correctness and compliance.

What are common CSDM adoption problems?

• Modeling applications as business services. The most common legacy pattern. It works until service portfolio management or event management needs the distinction CSDM draws.
• No business applications at all. Discovery fills the infrastructure tiers and the Design domain stays empty, so nothing links a server to what the business calls it.
• Custom classes for things that already have a class. A custom table for cloud databases that ignores cmdb_ci_database breaks inherited identification rules and connectors.
• Treating CSDM as a migration project. It is a target model. Organizations adopt it one domain at a time, usually Foundation and Manage technical services first.

How do you visualize the ServiceNow CMDB?

• Dependency views in the platform. The CI dependency view and the service map view show what one CI or one application service connects to. They suit one item, not a whole landscape.
• Exports and hand-drawn diagrams. Full control over layout, and out of date the day after.
• Connected architecture maps. Tools like Eraser connect to the ServiceNow CMDB alongside cloud accounts and other sources, and draw interactive maps across business applications, application services and infrastructure that update when the CMDB does.

Frequently asked questions