A configuration item (CI) is any component that needs to be managed to deliver a service, recorded in the configuration management database (CMDB) with the attributes and relationships that describe it. In ServiceNow, what makes a CI useful goes beyond the record itself. Its class decides which attributes it has and how it's identified. Its relationships decide what depends on it. Its life cycle stage and status decide whether processes treat it as live. Get those three right and the CI supports change, incident and security work. Get them wrong and the record exists but misleads.
Every CI belongs to a class in a hierarchy. At the top sits the base configuration item class. Beneath it, classes narrow down: hardware, then computer, then server, then specific server types. Application, database, network and service classes follow the same pattern.
The class decides three things:
Put a CI in too generic a class and it loses the attributes and identification rules it needs. Put it in the wrong class and moving it later is a delicate job, as our CI reclassification article explains.
Before creating a custom class, check whether an existing one fits. Custom classes need their own identification rules, and they're easy to forget at upgrade time.
The Common Service Data Model arranges CIs and related records into domains, from the foundation data that everything references, through design and build, to the services that are delivered and consumed.
In practice, the model tells you which class to use for each kind of thing and how they should relate. A business application describes what the business calls the application. An application service describes a deployed instance of it, in a given environment. Infrastructure CIs sit beneath application services and support them.
Following the model matters because ServiceNow's own features increasingly assume it. Change impact, service-aware incident management and many dashboards expect the relationships it describes.
A CI is only useful if every source that reports it agrees it's the same CI. That's the job of identification rules and their identifier entries, which name the attributes that uniquely identify a CI in its class.
| Class type | Typical strong identifiers | Common weak spots |
|---|---|---|
| Physical servers | Serial number | Placeholder serial numbers |
| Virtual machines | Hypervisor or cloud instance identifier | Clones sharing values |
| Network devices | Serial number, hardware address | Stacked devices reporting one serial |
| Applications and services | Name with host or entry point | Name reused across environments |
Our article on identification rules covers how to design and test them.
An isolated CI answers "does this exist?". Relationships answer "what happens if it fails?".
Discovery builds local relationships, such as software running on a server. Service mapping builds the chain from a service down to its infrastructure. Both matter, and a CI with no relationships at all should be treated as a question to answer before it's changed.
Run a monthly report of CIs in operational classes with no relationships. Each one is either unused, or used by something the CMDB doesn't know about.
ServiceNow originally tracked CI status through several separate fields, including install status and operational status. The Common Service Data Model now uses two standard fields instead: life cycle stage, which describes the overall phase, and life cycle stage status, which describes the state within that phase. Together they specify an object's status consistently across CIs, assets and other records.
Life cycle is where CIs most often mislead. Status set at procurement and never updated makes live equipment look like stock. Retired servers left in an operational state distort patch and vulnerability figures.
If you're moving from the older status fields, plan how existing values map to the new stages before switching, and check which processes and reports still read the old fields.
Track key performance indicators (KPIs) per class: CIs in the most specific appropriate class, CIs with complete identifiers, CIs with at least one relationship, and CIs whose life cycle agrees with discovery. Name an owner for each class's data model in the RACI (responsible, accountable, consulted, informed) for configuration management.
For the difference between a CI and an asset, see our earlier article. For the role of the CMDB overall, see the primary purpose of a CMDB.
Our two-week CMDB health baseline scores which CIs are trustworthy and which are guesses, class by class, including classification, identifiers, relationships and life cycle. The output is a report you can take to your change advisory board.
Our data quality assessment then measures the CMDB against weighted critical success factors, key performance indicators and metrics, and shows where de-duplication, normalisation and reconciliation are failing. We scope it with you at an initial consultation.
Book a CMDB diagnostic call or arrange a meeting with a consultant.
No. An asset is tracked for its financial and contractual value. A CI is tracked because it needs to be managed to deliver a service. Many things are both.
Only when no existing class fits and the difference matters to a process. Give it identification rules and an owner from the start.
The Common Service Data Model recommends life cycle stage and life cycle stage status. Check which of your processes and reports still read the older fields before changing.
Key attributes that its real type should have are missing, or it fails to match records from other sources that describe the same device.
Written by Iain Moone, Apex Configuration Group.