Choose a class model before choosing an import
A CMDB class describes what a configuration item is and which attributes and relationships should apply to it. ServiceNow classes form an inheritance hierarchy rooted in supported CI tables. A server, database instance, network adapter and business application represent different kinds of objects even when a discovery source labels all of them “assets.” CI Class Manager makes that model reviewable. If incoming integrations map unlike objects to one generic class, later identification rules and service queries can be wrong before the first dashboard opens.
ServiceNow documents CI Class Manager as the place to examine class hierarchy, table definitions, attributes, health settings and identification or reconciliation metadata. Begin by selecting one existing class that matches the intended resource; creating a custom child should solve a real modeling need, not give each department a slightly different name for a server.
In a fictional retailer, the cloud team discovers managed database instances and the application team manually registers a logical application. The former needs stable technical identification and operational ownership; the latter needs business purpose and lifecycle ownership. They should not be forced into identical mandatory fields or duplicate custom tables simply because they appear in one application portfolio.
Know inheritance and its operational consequences
A derived CI class can inherit columns and behavior from a parent. This is useful for consistency, but a change at a parent scope may affect many descendants. Before declaring an attribute mandatory, check which classes inherit it and whether each population can supply a meaningful value. A required serial number on a parent used by virtual or logical CIs can create widespread artificial incompleteness when the identifier does not apply to those descendants.
Identify the class table name, friendly label, inherited attributes and class-specific extensions during a review. A field present on a record is not proof it should be used for identity, and a display name is not a universally stable key. Documentation for a custom class should specify its business purpose, authorized sources, identifying attributes, expected relationships and data steward. That written contract keeps new integrations from inventing competing class mappings.
The ServiceNow table and record model defines how records and relationships are represented; a CI class also affects identification, reconciliation and downstream service use. For CIS-DF, the next level is understanding what a CI class means to IRE, CMDB Health and downstream service consumers. A class-model change should be tested with a representative import, duplicate check and impacted service query rather than treated as a cosmetic form redesign.
Separate independent from dependent CI identification
An independent CI can be meaningfully identified from its own evidence. A dependent CI requires the identity or relationship of another CI to be resolved reliably. A network adapter may depend on the host that contains it; a component running inside one application server may depend on a hosting relationship. Using only a common adapter name or process label could match two distinct dependent objects incorrectly.
ServiceNow describes dependent and independent classes and explains that dependent relationship rules are part of identification. Ask whether the parent CI exists before the child is resolved, which relationship type carries the dependency and what a missing parent does to the payload. Do not assume a CI is independent simply because it has a serial-like field.
Specific IRE and Discovery identification rules determine how incoming records match existing CIs. Class design precedes it: a perfect identifier in the wrong class can still produce inaccurate counts and broken service mapping. Test two hypothetical components with the same short name on different hosts. They should remain distinct when the parent context differs.
Make principal class selection purposeful
Principal classes identify important CI types for focused operational selection and governance views. They are not a declaration that every CI outside those classes is invalid or should be deleted. A company may focus incident and change forms on business-relevant infrastructure and application classes to reduce noise. A field technician selecting an affected CI should see meaningful choices without sorting through every ephemeral runtime object.
The principal class filter documentation notes that the designation applies to the selected class and is not automatically inherited by every child. That is important in a hierarchy with many subclasses. Choosing a broad parent can have a different operational outcome from selecting each supported principal class intentionally.
Review principal class choice with incident, problem, change and service owners. Ask which CIs they actually reference, which must appear in supported selection controls, and how the choice impacts health and dashboard scopes. Avoid designating classes solely to improve reported metrics by excluding difficult data populations.
Use mandatory and recommended fields wisely
A mandatory field affects data entry and can contribute to the required-fields component of CMDB Health when that metric is enabled. A recommended field is a softer quality expectation; it can expose omissions without imposing the same entry restriction. Neither proves that a populated value is accurate. A placeholder such as “unknown” may satisfy a presence check while undermining incident routing.
The mandatory-field guidance warns that configuration at dictionary scope has broader effects. For a newly modeled class, start from actual consumers: an incident team needs a responsible support group, a service map needs relationships, an asset process needs appropriate financial or lifecycle linkage. Define which source owns each field before requiring it.
A good design review lists the class, attribute, expected use, owning source, validation rule and consequence of absence. For example, business criticality may require a steward, while operating-system version is populated by a reliable technical feed. If there is no trustworthy source, making the field required will not create truth.
Test changes without disrupting the data estate
Before deploying a custom class or relationship rule, assemble example CI payloads, one correctly matching existing CI, one genuinely new object, one dependent CI without its required parent, and one with conflicting source attributes. Compare expected IRE behavior to the planned class model, then use multisource reconciliation for contested updates.
Document downstream effects: forms, imports, identifiers, dashboard grouping, asset references and impact maps. A newly introduced field might need historical backfill; an inherited mandatory setting can affect many classes. Make changes in a supported nonproduction environment and observe effects before broad rollout. This article describes a design and test method, not a claim of having deployed those changes.
Class Manager is valuable when it keeps CI meaning consistent. The best model is neither the flattest possible hierarchy nor the deepest possible one. It is the least complex hierarchy that reliably distinguishes resources, supports identification and makes operational questions answerable.
Review the cost of a class change in an operational example
A platform team proposes a new child class for managed databases to capture a vendor-specific version field. Before accepting it, ask whether an existing class already represents the resource, whether the new field is an attribute or a reason to create an entirely separate type, and which discovery or connector source will populate it. Then check which identification rules and relationship definitions apply. A new class that exists only to accommodate a source-specific label can fragment a database population and break saved service queries.
Now assume a change-management form filters for principal classes. If the new database child is not included when necessary, change owners might not select the affected CI. If a mandatory value inherited from the parent does not exist for managed databases, new records may fail a health check for reasons unrelated to business value. Class design, principal selection and health scope should therefore be reviewed together with the users of those records.
A reasonable acceptance checklist records the expected CI class on a sample payload, whether a repeated ingestion matches the same record, how a related application service reaches that CI, and which form or report must still find it. A design diagram alone cannot establish these outcomes; implementation needs a safe test in the applicable instance.
Decide when a relationship is a class dependency
Not all useful relationships are identification dependencies. A business service can depend on multiple application services, but that does not necessarily mean every service CI is identified only by the business-service record. Conversely, a network adapter may lack a meaningful identity without the containing host. A dependent identifier should use a stable, semantically required parent relationship; a merely helpful diagram edge should not become an arbitrary prerequisite for creating a CI.
When a parent changes during a legitimate lifecycle event, review how the child should be identified. A VM migrating between hosts may preserve identity, while an interface physically belonging to another device may represent a different object. These distinctions require product-specific class and identification rules. Avoid adopting a generic rule such as “every child gets the parent hostname” without collision tests.