ServiceNow CMDB Class Explained

What a CMDB Class Is

A CMDB class is a template that defines the structure of a particular type of configuration item. Classes specify which attributes each configuration item must or may have, what data types those attributes use, and how items of that class relate to other items. Think of a class as the schema for a category of infrastructure component: servers, databases, applications, or network devices all have their own classes that define their relevant attributes.

When you create a new configuration item in the CMDB, you assign it to a class. The class determines what information the system will store about that item. A server configuration item includes attributes like hostname, operating system, installed memory, and network configuration. A database configuration item includes attributes like database name, version, owner, and backup schedule. Each class captures the information that is relevant to items of that type.

Where CMDB Classes Live in ServiceNow

CMDB classes are defined in a hierarchy within the ServiceNow platform. The root class is called cmdb_ci, which represents the base concept of a configuration item. Specialised classes inherit from this root and add attributes specific to different types of items. For example, cmdb_ci_hardware is a class for hardware items, and cmdb_ci_server is a more specific class for servers.

You can see the class hierarchy through the CMDB administration interface. Each class is a table definition, and the configuration item records in it sit in that table, which extends the cmdb_ci base table. You reference a class by its class name, also called the sys_class_name. The class structure is hierarchical, meaning that child classes inherit all attributes from their parent classes and then add their own attributes on top.

When you browse the CMDB, you interact with classes through views that show items of a particular class. You can also query across multiple classes when you need to see related items of different types. The class structure determines what information you can see and store about each type of item.

A Worked Example: Understanding Server Classes

Suppose you want to track both physical servers and virtual machines as configuration items. ServiceNow provides separate classes for these: cmdb_ci_server is the class for physical servers, and cmdb_ci_vm_instance is the class for virtual machines. Both inherit from cmdb_ci_hardware, which defines common hardware attributes like manufacturer and model.

The server class includes attributes like hostname, serial number, memory, CPU count, and installed applications. The virtual machine class includes those same attributes plus additional ones like hypervisor, virtual CPU count, and allocated memory. When you create a new virtual machine in the CMDB, you assign it to the cmdb_ci_vm_instance class, and the system knows to collect the virtual machine-specific attributes along with the general server attributes inherited from the parent class.

When you need to find all computers in your infrastructure, you can query the cmdb_ci_hardware class, which returns both physical servers and virtual machines. When you need only virtual machines, you query the cmdb_ci_vm_instance class. The class hierarchy makes it possible to ask questions at different levels of specificity.

Common Misunderstandings About CMDB Classes

A frequent confusion is thinking that classes are just labels or tags. They are not. Classes define the database schema for items. When you change an item’s class, you are not just re-labelling it; you are changing what attributes are stored and what relationships are possible. Class changes should be infrequent and carefully planned because they affect data structure.

Another misunderstanding is assuming that every organisation should use classes exactly as ServiceNow provides them out of the box. ServiceNow’s standard classes cover common scenarios, but organisations often extend these classes to capture attributes specific to their environment. Extensions allow you to add custom attributes to classes without modifying the standard classes that ServiceNow maintains.

Some organisations incorrectly assume that having many classes means better structure. In reality, excessive class hierarchies become difficult to maintain and query. Most organisations succeed with the standard class hierarchy plus targeted extensions for custom attributes.

Related Concepts and Integration Points

Class structure relates directly to CMDB data quality. If you have classes that are too broad, they may not capture necessary details. If you have classes that are too specific, discovery and data entry become complex. Finding the right class structure requires understanding your infrastructure and what information matters for your operational decisions.

Discovery integration depends on class structure. Discovery tools import infrastructure data and assign items to appropriate classes. The quality of that assignment depends on whether your class hierarchy matches your actual infrastructure. Tables like cmdb_ci_disk_drive, cmdb_ci_network_device, and cmdb_ci_application represent common infrastructure categories with their own classes.

Application portfolios, capacity planning, and incident impact analysis all depend on understanding class hierarchies. When you need to find all items of a particular type or find items with particular attributes, you query based on class structure. Effective use of ServiceNow requires understanding how classes organise your configuration data.

When a new class is justified and when an existing one is enough

The most consequential CMDB design decision is whether a configuration item belongs in an existing class or needs a class of its own. Teams often create a new class because a single attribute is missing, then find that the new class carries relationships, discovery rules and reports that now have to be maintained twice. A class should exist because the items in it share attributes, relationships and a lifecycle that differ from the items in the nearest parent. A missing attribute is often better handled by extending the parent class, and a difference in discovery source is often better handled by the discovery configuration.

Ask who will use the distinction. If reports, reconciliation rules or service mappings need to treat the items differently, a separate class earns its place. If the only consumer is one person’s spreadsheet, the class is probably too specific.

Deciding between a subclass, an extension and a plain attribute

Option	Use it when	Cost to maintain	Typical mistake
Use an existing class as is	The items match the class’s attributes and relationships	Lowest	Forcing items into a class that does not describe them
Extend an existing class with attributes	The items need extra data but the same behavior	Moderate; the extension must be reviewed at upgrades	Adding attributes that only one team reads
Create a subclass	The items have distinct relationships, lifecycle or discovery	High; every report and rule must account for it	Creating it for a difference that belongs in a field

A useful test is to list the three most common questions asked about items of the proposed class. If the answers can be produced from the parent class with one extra field, do not create a subclass. If the answers need relationships that do not exist on the parent, the subclass is justified.

Steps for changing the class design safely

1. Write down the business question the change is meant to answer, and the people who will use the answer.
2. Count the existing items that would move, and check which of them are currently linked to other items.
3. Identify the discovery sources that populate the class, and decide which source is authoritative for each attribute.
4. Test the change in a non-production copy with a sample of items, and confirm reports and reconciliation still produce the expected results.
5. Plan the migration of existing items, including the handling of relationships that do not carry over.
6. Record the reason for the class in the data dictionary or design note, for whoever maintains it next.

Symptoms that the class design is wrong

• Items appear in two classes because discovery and manual entry disagree about where they belong.
• Queries against a parent class miss items that clearly belong to it, because they were placed in a sibling by mistake.
• Reconciliation keeps creating duplicates across classes, which often means the identification rules were written for only one of them.
• Administrators are reluctant to change anything, because nobody knows which reports depend on which class.

The last symptom is often the most serious. A class design that cannot be changed without fear is one that has grown without an owner. Assigning an owner and a short design record is a cheap fix.

When not to extend the model at all

Stop before creating a class when the real need is to track something that is not a configuration item, such as a contract or a license. Those belong in their own records, linked to the items they cover. Also stop when the team cannot name the owner who will keep the new class accurate. A well-designed class with no owner decays into the same problem it was meant to solve.

Can a class be renamed later?

Renaming changes how the class is referenced, so it should be treated as a migration rather than a label change. Plan it with the same care as any change to the data structure.

Who should approve a new class?

The CMDB owner with a representative of the teams that will use it. Approval from the people who need the data prevents a class that is technically correct but useless for reporting.

Does a subclass inherit the parent’s relationships?

Generally it inherits the attributes of its parent, but relationship rules and reporting definitions must be checked explicitly in the instance being configured. Do not assume they carry over unchanged.

How do I tell whether the design is working?

Items should be found by their class without manual searching, reconciliation should produce few exceptions, and the teams that use the data should be able to answer their own questions without a request to the CMDB owner.

Next step

If the class structure has grown faster than its ownership, a review of which classes are needed, and why, is a practical starting point. For who should answer for each class, see the CMDB ownership model article, and for how items are matched to the right class, see the identification and reconciliation guide.

Common ServiceNow CMDB classes and how to see the hierarchy on your own instance

Most ServiceNow CMDB classes sit beneath the root table cmdb_ci, and the classes teams meet first are computers and servers, network devices, applications, databases and services. The exact list depends on the plugins installed, so the reliable way to see your own class hierarchy is the CI Class Manager in the CMDB application, not a list copied from another instance.

Table name	What it typically holds
cmdb_ci_computer	Computing hardware such as servers and workstations
cmdb_ci_server	Servers, with operating-system classes such as cmdb_ci_win_server and cmdb_ci_linux_server beneath it
cmdb_ci_vm_instance	Virtual machine instances
cmdb_ci_netgear	Network devices such as switches and routers
cmdb_ci_appl	Application instances running on hosts
cmdb_ci_db_instance	Database instances
cmdb_ci_service	Service records that sit above the infrastructure

Reading the hierarchy in the CI Class Manager

Open the CI Class Manager, select a class, and the hierarchy view shows its parents and children, the attributes each level adds, and the relationships the class is allowed to have. Read it from the top down. A parent shows what every child inherits, and a child shows only what makes that class different, which is why an attribute added to a parent appears on every class beneath it.

Find the classes that actually hold data

A default instance carries far more classes than most organisations use. Group your configuration item records by class name and sort by count, and a short list of classes with real data appears. Classes with no records are rarely worth a design decision, and a class holding a handful of records deserves a question: is it a genuine exception, or are those items sitting in the wrong class?

The configuration item definitions page explains where to draw the boundary between one kind of item and another, the Common Service Data Model guides cover the service layer above these classes, and the CMDB data quality and governance page shows how class choices affect the checks you can run.