CMDB Configuration Items

What are configuration items?

A configuration item is any component of your ServiceNow estate worth tracking individually: a server, an application, a database, a network device, a business service. What makes something a CI rather than just an entry in a spreadsheet is that it sits in the CMDB with a defined class, attributes, and relationships to other CIs, governed by the Common Service Data Model (CSDM).

Physical and virtual infrastructure

Applications, databases, and software

Network topology

Cloud resources

Business services

Ownership

Who is accountable for the CI, so a question about it has somewhere to go.

Location

Where it physically or logically sits, from a data centre rack to a cloud region.

Lifecycle stages

Whether it's in build, live, or scheduled for retirement, tracked against its actual state.

Configuration details

The specific attributes that make the CI useful, not just present, such as version, capacity, or configuration.

Relationships to other systems

What it depends on and what depends on it, recorded in the relationship table.

Why CI structure matters

A well-structured CI model ensures:

Consistent data across your CMDB, because every server, application and service is classed the same way instead of however the team that added it happened to name it
Clear relationships between systems, so a change to one CI shows what else it touches
Accurate service mapping, because service mapping can only be as reliable as the CI classes and relationships it reads from
Reliable reporting, since a report run against inconsistent classes produces numbers nobody trusts
Compatibility with other processes and ServiceNow modules, including anything built on the Common Service Data Model (CSDM)

Poor CI modelling leads to confusion and unreliable data, and it compounds: every integration and workflow built on top of a bad model inherits its problems.

Skyscrapers seen from below against a blue sky

Creation

Updates and changes

Decommissioning

Without active lifecycle management, data quickly becomes outdated: CIs that no longer exist stay listed as live, and CIs that do exist never get logged. CMDB best practice is what keeps the model current rather than accurate only on the day it was built.

Getting the CI class hierarchy right

ServiceNow ships with a base CI class hierarchy under the Common Service Data Model, and most of the thin CMDBs we see didn't extend it correctly: teams either force every new component into the closest existing class whether or not it fits, or create a new class for every variation and end up with dozens of near-duplicate classes that report differently. Both make the model harder to query and easier to get wrong.

The fix isn't more classes. It's extending the CSDM hierarchy only where the business genuinely needs to report or automate differently by class, and mapping everything else back to a class that already exists.

The same pattern shows up in ownership fields. A CI class with an ownership attribute that's optional rather than mandatory ends up half-populated, and half-populated ownership is functionally the same as no ownership when an incident needs an answer in minutes, not after someone has gone through three ticketing systems to find out who's responsible.

The outcome

Structured, reliable configuration data

Improved visibility across your configuration items

Better incident and change management

Compatibility with ServiceNow modules via CSDM compliance

Not confident in your configuration item structure?

Our data quality assessment scores your CI model against named critical success factors and shows exactly where de-duplication, normalisation and reconciliation are failing, or start with a CMDB health check.