An asset inventory can be technically complete and still be unusable if everything has been placed in the wrong class. A server record might be represented as generic hardware; an application might be confused with the server that hosts it. Those mistakes spread into discovery, identification rules, health metrics and outage analysis. In ServiceNow, class design is therefore not cosmetic database administration. It determines what a CI means, what attributes it inherits, and which controls should apply to it. CI classification and relationships define the underlying model; here the focus is on operating CI Class Manager, choosing principal classes, and safely changing a classification that already contains production records.
A retailer whose cloud platform and endpoint tools both report virtual machines needs stable CI classes before it can reconcile either source. The ServiceNow CIS-DF configuration domain includes CI Class Manager and identification rules because a class hierarchy defines what each record represents and which attributes it can inherit. Model servers, applications and service instances according to their meaning; then test whether both inventories identify the same machine without confusing its software with its host.
A class should describe the thing, not its latest data source
Start with an operational definition. Is the record a physical server, a virtual machine, an installed software component, a business application, or an application service? A connector name such as “cloud scan” is not a class definition; it tells you where data came from. Similarly, location, owner and environment are attributes, not reasons to invent separate CI classes for every department. When the definition depends on the ingestion method, records drift whenever that integration is replaced.
A practical review uses three real examples from different teams. Ask what the item represents, which attributes every instance should carry, how it is identified after a hostname change, and which other CIs it can legitimately depend on. If the proposed custom class adds no stable behavior or reporting distinction beyond its parent, the parent class may already be sufficient. The objective is a model with clear semantics, not the maximum number of leaf classes.
Read inheritance before adding an attribute
CI Class Manager exposes the CMDB class hierarchy and the attributes and rules associated with each class. A child class inherits relevant behavior from its parents, which makes inheritance powerful and dangerous. Adding a required attribute high in the hierarchy could affect unrelated descendants that cannot provide that value. Conversely, placing an important identifier only on a narrowly specialized class may leave sibling integrations unable to identify the same technology consistently.
Before altering a class, inspect where the property should live and whether the proposed type, default or requirement is valid for all inheriting CIs. Review dictionary changes, reference targets and downstream filters. A common failure is to make a field mandatory because one integration always supplies it, then discover that older records or a second source cannot populate it. A development-instance test with real sample records is more informative than a configuration screen that saves without errors.
Principal classes are a governance decision
Principal classes let teams concentrate CMDB health and stewardship on the CI classes that matter most to their operations. A bank might begin with application services, servers and critical network equipment rather than scoring every miscellaneous record equally. This is not a license to ignore the rest of the CMDB. It is a way to direct the most active measurement and remediation effort toward data that actually affects incidents, changes, asset accountability and service continuity.
Selecting principal classes requires a documented rationale: business criticality, population size, operational ownership and whether reliable data sources exist. If nearly every class is declared principal, prioritization disappears. If only the easiest-to-populate class qualifies, the dashboard can appear healthy while important business dependencies remain inaccurate. Treat CMDB Health indicators and governance as complementary: health measures expose quality gaps, while stewardship assigns corrective responsibility. Principal-class configuration determines which critical CI populations these checks cover.
Identify the CI before assigning attributes
Class selection directly affects the Identification and Reconciliation Engine (IRE). Identification rules are designed for particular CI populations and use stable attributes to decide whether an incoming payload describes an existing record. A virtual machine incorrectly classified as a generic application may miss its intended identifiers and create a duplicate. Attribute reconciliation then decides which trusted source may update each field, but it cannot repair the conceptual classification on its own.
Use controlled sample payloads from both discovery and external connectors. Check the proposed class, identifiers and resulting operation before allowing a production batch. If the payload identifies an unexpected class, correct the mapping and re-test. Do not solve a mapping problem by inventing an overly broad identifier rule that makes unrelated assets collide. A correct Identification and reconciliation decision depends on stable identifiers and source authority; Service Graph and ETL must preserve those fields through transformation so the IRE can apply them consistently.
Separate the class of an application from its running instance
A business application describes an application from a portfolio and ownership perspective; an application service represents a deployed service instance used in operations. The Linux hosts beneath it belong in infrastructure classes. Collapsing these into a single generic “application CI” makes it difficult to assign a change to the right operational object or to decide whether a service outage affects a consumer. Correct classing is the prerequisite for meaningful service relationships.
Suppose payroll has a production service instance and a staging instance under the same business application. They require distinct operational relationships and change controls even though they share portfolio ownership. The CSDM 5 stakeholder model separates planned applications from deployed service instances, so a class designer should represent environment and supported-service relationships without creating an unnecessary custom class for every deployment stage.
Treat relationship constraints as part of the model
Relationships such as “runs on,” “depends on” and “hosted on” answer different operational questions. The class hierarchy influences what kinds of connections are plausible, while a relationship’s direction changes how an impact map is interpreted. An application service depending on a database is not equivalent to a database depending on the service. Inventing a relationship to make an attractive diagram can corrupt outage-impact reasoning for every future user of the map.
Validate class changes with a small dependency query, not only a form view. Look at representative parent and child relationships, related incidents and the service instances that would be affected. Unified Map dependency impact reveals why a seemingly harmless class change can alter what people conclude from a service-impact view. Record the intended relationship types in design standards so the next integration does not improvise its own graph.
Plan a change for existing production records
Moving an established CI population to a different class is more consequential than creating a new class. Assess identification behavior, inherited fields, references, relationship constraints, reporting filters, business rules, access controls and integrations that depend on the current table. Take a representative inventory snapshot and identify the source systems that would re-send the records after migration. A technically successful move can be reversed by the next uncontrolled ingestion job.
Schedule class restructuring as an explicit governed change. In a lower environment, test the source payloads before and after migration, confirm reference preservation and compare distinct CI counts. Establish who is authorized to approve the new semantic definition. For a large population, migrate a bounded sample first and inspect health and reconciliation effects. When reclassification is unsafe, a new mapping for future records plus a staged remediation path may be more practical than a mass update.
Use health measures to verify the design
A class change should improve the usefulness of data, not merely reduce error messages. Compare pre-change and post-change duplicate rates, identifier conflicts, completeness of required fields, class-level ownership and relationship health. Include a negative test: two different devices with similar names should remain different CIs, while one device reported from multiple authorized sources should still resolve to the same CI. Both matter more than seeing a successful import job.
The Data Foundations dashboards can indicate quality deterioration after a change, but the team must interpret their scope. A better score from excluding difficult records is not a better CMDB. Investigate whether the corrected class allows incident responders and service owners to answer questions more reliably. Build an exception report for records that do not fit the classification rather than silently forcing them into the nearest available class.
Decide when a custom class is justified
Custom classes can be useful for genuinely different technical objects that require distinct inherited attributes, identification behavior or operational relationships. They are poor substitutes for better naming standards or missing reference data. Before building one, search the existing hierarchy and evaluate whether a standard class has recently gained the necessary capabilities. The maintenance burden includes connectors, dashboards, permissions, upgrade testing and documentation for every future team.
If custom behavior is unavoidable, establish an owner, a definition, sample records, and a policy for how sources populate and retire the class. Review how that class participates in CSDM, Data Manager policy selection and discovery. A custom class without a controlled source may soon contain contradictory records. A standard class without enough stewardship can suffer the same fate, so the choice is not “customization versus governance”; it is whether the new semantics justify their long-term operational cost.
Diagnose a classing incident without deleting CIs
Imagine a new discovery pattern classifies a fleet of container hosts as ordinary servers, while another integration writes them as virtual machines. The count of apparently missing systems climbs, and the duplicate dashboard begins showing pairs with different references. Start with sample payloads and current class assignments. Determine whether these records are genuinely the same item, then inspect identification rules and source mappings. Do not merge hundreds of records simply because the names look similar.
After a class change, trace a known device through duplicate CI remediation checks and CMDB Workspace stewardship. Confirm that a previously valid identifier still resolves correctly, that related incidents and service dependencies remain attached and that an owner can approve the resulting data-quality correction. Correcting only the displayed class name can leave the underlying ingestion defect untouched.
Choose the CI class from its operational purpose
A typical exam-style scenario describes records that are classified inconsistently, quality measures that omit a key population, or an integration that creates duplicates despite having identifier values. Ask whether the immediate problem is the class model, identification rule, reconciliation authority, data-source transformation or relationship semantics. CI Class Manager and principal-class configuration are relevant when the meaning and governance scope of the population are wrong; they are not a universal substitute for fixing source payloads.
For practical study, work through one standard class, one inherited field, one principal-class decision and one integration that populates it. Document the expected record class and identity before testing. Inspect health outcomes and one dependent service afterward. That small workflow teaches the architectural reason for each control and makes exam decisions easier to distinguish from plausible but misplaced alternatives.