The ServiceNow CMDB is built around one foundational concept: every piece of infrastructure, software, or service that matters to your business is represented as a Configuration Item. But a CI on its own is only useful if it is classified correctly. The CI class in ServiceNow determines what attributes a record carries, how it relates to other items, and whether the data it holds is trustworthy enough to act on. Getting this right is not a cosmetic concern. It shapes how workflows run, how dependencies are mapped, and how AI-driven processes interpret your environment.
This article breaks down what a CI class actually is, how the class hierarchy works, how to choose the right class for a given item, and what goes wrong when classification decisions are made carelessly.
What a CI Class Represents
A configuration item class is the template that defines what a CI is and what data it can hold. Every CI in the ServiceNow CMDB belongs to a class, and that class determines the table the record is stored in, the attributes available on that record, and the relationships it can form with other CIs.
Think of a class as a contract. When a CI is assigned to the cmdb_ci_linux_server class, that contract says the record should carry attributes like operating system version, CPU count, memory, and host name. It also signals to ServiceNow processes, discovery, service mapping, change management, and AI Agents, what kind of item this is and how to handle it. Without a class, a CI is just a row in a table with no meaningful structure.
Classes are not arbitrary groupings. Each one corresponds to a specific type of infrastructure or service component, and ServiceNow ships with a large library of predefined classes covering servers, databases, network devices, cloud resources, applications, and more. Custom classes can also be created when the out-of-the-box library does not cover a specific need, though this should be approached carefully to avoid fragmenting the model.
Class Hierarchy Basics
The CI class hierarchy in ServiceNow follows an inheritance model rooted in the base table cmdb_ci. Every class in the CMDB extends from this root, either directly or through intermediate parent classes. This structure is what makes the CMDB scalable and consistent across very different types of infrastructure.
How Inheritance Works
When a class inherits from a parent, it automatically receives all the attributes defined on that parent. A child class then adds its own specific attributes on top. For example, cmdb_ci_computer extends cmdb_ci and adds attributes relevant to any computing device. cmdb_ci_server extends cmdb_ci_computer and adds server-specific fields. cmdb_ci_linux_server extends cmdb_ci_server and adds Linux-specific attributes. Each level adds specificity without discarding what came before.
This inheritance chain matters for queries, reporting, and service mapping. A query run against cmdb_ci_server will return records from all its child classes, Linux servers, Windows servers, and any other server subtypes. This makes it possible to work at the right level of abstraction depending on the task at hand.
The Role of the CSDM
The Common Service Data Model (CSDM) adds a layer of structure on top of the class hierarchy by defining how CI classes map to business services and technical services. The CSDM is not a replacement for the class hierarchy. It works alongside it, ensuring that the right classes are used in the right context for service-aware operations. Understanding both the class hierarchy and the CSDM is essential for anyone managing a mature CMDB implementation.
Choosing the Correct Class
Selecting the right CI class is one of the most consequential decisions in CMDB design. The correct class is the most specific one that accurately describes the item, not so broad that it loses meaning, and not so narrow that it forces attributes that do not apply.
Start with the Item’s Function and Technology
The starting point is always the nature of the item itself. A physical server running Linux should be classified as cmdb_ci_linux_server, not simply cmdb_ci_server or cmdb_ci_computer. Using a parent class when a more specific child class exists means losing attribute coverage and reducing the CMDB’s ability to support automated processes like discovery reconciliation and impact analysis.
For cloud resources, ServiceNow provides classes like cmdb_ci_cloud_service_account, cmdb_ci_vm_instance, and provider-specific subtypes. These classes exist because cloud infrastructure has attributes and relationship patterns that differ meaningfully from physical hardware. Forcing a cloud VM into a generic server class is a common mistake that degrades service mapping accuracy.
When No Class Fits Exactly
Sometimes the standard library does not cover a specific item type. In these cases, creating a custom class that extends the nearest appropriate parent is the right approach. What to avoid is using a generic class like cmdb_ci itself as a catch-all. A CI parked at the root level carries almost no structured data and contributes little to any downstream process that depends on class-specific attributes.
Before creating a custom class, it is worth reviewing the full class hierarchy carefully. ServiceNow’s library is extensive, and the correct class is often already there, just not immediately obvious. Reviewing the CSDM documentation alongside the class hierarchy can surface options that a quick search might miss.
Impact of Misclassification
Misclassification is one of the most damaging and least visible data quality problems in a ServiceNow CMDB. A CI assigned to the wrong class will appear to exist in the CMDB, but the data it holds will be incomplete, structurally incorrect, or misleading to every process that consumes it.
The consequences are practical and immediate. Service mapping cannot accurately build service graphs if the CIs it discovers are classified at the wrong level. Discovery reconciliation rules are class-specific. A CI in the wrong class may be duplicated rather than matched to an existing record. Change management workflows that rely on CI attributes to assess risk will work from incomplete data if the relevant attributes simply do not exist on the record’s class.
For AI Agents and automated workflows, misclassification is particularly damaging. These processes depend on structured, class-appropriate data to make decisions. A CI that looks like a server but is classified as a generic configuration item provides no useful signal. The AI Agent either ignores it or makes an incorrect inference. Neither outcome is acceptable in a production environment.
Misclassification also tends to compound over time. Once a CI is created in the wrong class, relationships built from it propagate the error. Correcting classification after the fact requires not just moving the record but auditing and repairing the relationships and attribute data that were built on the incorrect foundation.
Identifying misclassified CIs at scale requires systematic auditing against defined class rules. This is where a tool like Data Content Manager provides real value. We built it specifically to help teams define what correct looks like for each CI class and surface violations without scripting or custom development. Instead of discovering misclassification problems reactively, teams can enforce class-level data rules proactively and get a clear picture of where the CMDB deviates from the intended model.
If classification issues are affecting the reliability of your CMDB or the effectiveness of your ServiceNow workflows, get in touch with us to see how DCM can help.
