A CMDB class is a promise about what a record represents. If physical servers, virtual machine instances, database components, and logical application services are all placed in the same generic class, the platform loses the distinctions needed for identification, governance, and relationship validation. ServiceNow’s CI Class Manager helps administrators inspect and manage the Configuration Management Database (CMDB) class hierarchy, its attributes, identification rules, and related settings. In the CIS-DF exam, class selection is an architectural decision with direct consequences for the quality of incoming data and the usefulness of operational insight.
Read class inheritance before creating a custom CI class
ServiceNow CMDB classes belong to a hierarchy. A child class inherits common attributes and behavior from its parent, and can define more specific fields and constraints appropriate to its type. The base Configuration Item class cmdb_ci establishes shared properties for CIs, while descendant classes represent more precise managed objects. A server CI and an application service are both parts of the CMDB but are not interchangeable instances of one generic “technology” concept. The value of inheritance is controlled reuse: consistent identity, ownership, and lifecycle fields without copying them into every class definition.
Before introducing a custom class, inspect the existing hierarchy and the intended object. What does the object do? Is it already represented by a standard class or an approved extension? Does its identity depend on another CI? Which attributes are genuinely specific to the new kind of object? Which platform applications already rely on the expected standard class? Creating a custom class merely because an external source calls an item by a different noun increases integration and upgrade complexity. A class name should represent a stable semantic distinction, not one supplier’s export column.
Suppose an inventory integration contains “Hosted Database Node” as a source type. This might map to a standard database instance class, a physical or virtual server class, or a specialized child class depending on what the record actually represents. A node that is the host itself should not also be used to represent the software database instance it runs. The class decision changes which identifiers work, what relationships can be validated, and how consumers interpret the CI in incidents and change records. It should be reviewed by someone who understands the runtime architecture, not inferred from the import file title.
Decide which attributes describe identity, state and governance
Attributes have different responsibilities. A stable unique identifier helps establish which real-world object a record represents. Operational state describes whether that object is active or in service. Ownership attributes identify groups accountable for supporting the record. Source metadata helps explain how a value arrived. Treating all attributes as equal can produce fragile identification rules or misleading completeness scores. For example, a display name is convenient for a human list but may be an unsafe unique identifier when names can be reused across environments.
ServiceNow’s identification rules can include combinations of attributes, and dependent identity can use relationships to another CI. A child CI representing a component installed inside a host may need the host’s identity plus a local component identifier. If a class is chosen too broadly, two legitimate different components may match accidentally; if it is chosen too narrowly or depends on a volatile field, every new observation can create a new CI. The distinction between identity matching and source-authorized attribute updates is treated in the CMDB identification and reconciliation workflow. CI Class Manager is where that class context must make sense before any feed is enabled.
For an operationally important class, define a small, defensible set of required and recommended fields. The requirements should support real questions such as ownership, impact analysis, reporting, and remediation. Marking every possible attribute mandatory increases incomplete records without improving decision quality. Conversely, an application service with no named owner and no representation of its deployed dependency may look neat in a generic CI list but cannot support a useful incident escalation path.
Use CI Class Manager to inspect the inheritance chain
A practical class-design review begins by navigating the existing hierarchy in CI Class Manager and selecting the intended class. Inspect the inherited attributes as well as class-specific definitions; an apparently missing attribute may be inherited from a parent rather than absent. Then review identification and reconciliation configurations relevant to the class and its ancestors. A parent-level rule may apply to several subclasses, while a more specific rule can change behavior for a child. Changes to a broad parent class deserve a larger blast-radius review than changes to a specialized class.
Also inspect supported relationship types and dependent class expectations. A class can be structurally valid yet operationally disconnected if its required dependencies are unknown or incorrectly modeled. A network appliance class may use interface CIs and physical connections; an application service must express application-level dependencies. Those different relationships are not merely presentation details: they influence service impact, discovery behavior, and evidence used by downstream ServiceNow products. Consult the CI Class Manager documentation for available actions and release-specific interface behavior.
Avoid changing class definitions in production while experimenting. Use a training or sandbox instance to learn how properties behave, including inherited field definitions and the results of adding or removing a relationship rule. In a working environment, changes should be reviewed with affected integration owners, data stewards, and teams that depend on the class. A schema change can be technically permitted yet still invalidate an external transform map or reporting filter.
Define principal classes around the CMDB’s operating mission
Not every class has the same business importance. A CMDB containing thousands of low-value observation records may need to focus governance attention on the classes that meaningfully support service management and operational use. Principal classes provide a way to identify a meaningful population for specific CMDB Data Foundations and governance activities. They should not be chosen simply because those classes are easiest to make healthy or because administrators want to hide noisy subclasses.
Imagine a retailer with a critical point-of-sale platform. Servers, payment application services, database instances, network devices, and certain business service objects may be central to outage impact and change control. A one-off imported device category with no supported use case might be lower priority. Principal-class decisions should reflect the operational questions the enterprise must answer, available authoritative sources, and the ability to maintain important CIs. A useful governance note states which classes are principal, why, who owns the decision, and when it will be revisited.
Principal class selection must not be confused with the concept of a parent class in inheritance. Parent classes define structure; principal classes reflect business-relevant attention and scope. The same class can participate in the inherited hierarchy whether or not it is considered principal for a particular governance dashboard. That distinction is easy to lose if someone treats “principal” as a synonym for “top-level.”
Connect class choices to health and data quality
The CMDB Health process depends on knowing which records and rules are in scope. A server class may have defined staleness rules, required support-group information, and expected relationships. A logical business application should not automatically inherit the same evidence expectations as an agent-discoverable server. If a quality report labels an entire class stale, revisit the class-specific refresh rule and source before changing hundreds of individual CIs. A model built without considering source behavior will create recurring data-quality exceptions.
Similarly, an asset record and a CI may represent different aspects of the same physical item. An asset can capture procurement, financial ownership, or disposal lifecycle; the CI captures configuration and operational dependencies. A class decision should not collapse the two perspectives into one record with incompatible fields. Align them through the platform’s intended data relationships and lifecycle mappings where appropriate.
A good class owner can explain what makes the population complete. “Every instance from cloud account A is present as a cloud server CI” might be testable against a source inventory. “All important technology is in the CMDB” is too vague. Class-level completeness is best judged against a measurable and authorized source, alongside checks for duplicate identities, orphan relationships, stale updates, and fields essential to operational work.
Test a model with a deliberate boundary case
In a sandbox, choose an existing server class and inspect its parent chain, inherited identification fields, and class-specific attributes. Add a conceptual database component that lives on that server, then ask whether the component belongs in the host’s class or needs a separate database-related class. State its stable identifier and the relationship to the host. Use a second host with an identically named database component to see why parent-aware identity can matter. Do not assume a component name is globally unique.
Next, imagine importing server details from two sources. One has trustworthy hardware identity; the other has more current operational state. Record which attributes each source is authorized to maintain and which class-level rules apply. Compare what the class owner wants to see in a health dashboard with the model’s actual fields. If a rule causes false positives for all virtual machines, locate the error at the appropriate class or governance scope rather than mass-editing each CI.
Finally, map the sample records to a service instance only where the dependency is real. ServiceNow’s CSDM relationship approach explains why a logical portfolio entity and a deployed CI graph require different modeling decisions. The central CIS-DF lesson is that classes must be designed for truthful identity, maintainable ingestion, and useful downstream questions. A neatly organized hierarchy that cannot support those three tests is not yet a trustworthy configuration model.