A configuration item is only as useful as the data it holds. When CI records are missing key attributes, contain inconsistent values, or carry fields that no one maintains, the configuration management database stops being a source of truth and starts becoming a source of noise. Getting the attribute selection right from the start is one of the most practical steps any team can take to improve CMDB quality and keep ServiceNow workflows running on accurate information.
There is no single universal field list that works for every organisation or every CI class. The right approach is to define selection criteria that guide which attributes belong on a record and which do not. This article walks through those criteria by category, covering identification, ownership, lifecycle, and class-specific requirements, so teams can make deliberate decisions rather than inheriting whatever fields happened to be there by default.
Identification Attributes
Identification attributes are the foundation of any CI data model. Their purpose is to make a record uniquely identifiable, discoverable, and distinguishable from every other record in the CMDB. Without reliable identification data, deduplication fails, discovery tools create ghost records, and reconciliation between data sources becomes guesswork.
The criterion for including an identification attribute is straightforward: does this field help uniquely locate or verify this CI, either by humans or by automated processes? Fields that meet this bar typically include:
- Name and display name — the human-readable label used across the platform
- Serial number or asset tag — physical identifiers for hardware CIs
- IP address and FQDN — network identifiers used by discovery and monitoring tools
- Correlation ID — a reference used to match records across integrated systems
- CI class — the record type within the CMDB hierarchy
A field like “notes” or “description” rarely qualifies as an identification attribute, even if it sometimes contains useful context. The test is whether the field is used in any matching, deduplication, or lookup logic. If it is not, it belongs in a different category or should be reconsidered entirely.
Ownership and Support Attributes
Once a CI can be identified, the next question is: who is responsible for it? Ownership and support attributes define accountability and determine how the platform routes incidents, change requests, and service requests. These fields are among the most operationally critical in any CI record because they directly affect workflow behaviour in ServiceNow.
The selection criterion here is accountability: does this field establish who owns, manages, or supports the CI in a way that the platform can act on? Relevant attributes typically include:
- Managed by — the individual or team responsible for the CI day to day
- Owned by — the business or technical owner, often used for governance and reporting
- Support group — the assignment group that handles incidents and requests related to this CI
- Vendor or manufacturer — relevant when support is provided externally under a contract
- Location — physical or logical placement, which affects support routing and impact assessment
Ownership fields are also a common source of data quality problems. When they are populated at the time of discovery but never maintained, they drift out of date quickly. Any attribute in this category should have a clear owner and a defined process for keeping it current, not just a field that gets filled in once and forgotten.
Lifecycle Attributes
Lifecycle attributes capture where a CI sits in its operational lifespan. They support decisions around procurement, retirement, compliance, and risk, and they give teams the context needed to understand whether a CI is actively managed or has quietly become a liability.
The criterion for lifecycle attributes is temporal relevance: does this field reflect a meaningful stage or date in the CI’s existence that affects how it should be treated? Common lifecycle fields include:
- Operational status — whether the CI is in production, in maintenance, retired, or in another defined state
- Install date and commissioned date — when the CI was placed into service
- End-of-life and end-of-support dates — critical for risk management and vendor support planning
- Decommission date — when the CI was or will be retired
- Warranty expiration — relevant for hardware CIs under maintenance contracts
Lifecycle data is particularly valuable when it feeds automated processes. In ServiceNow, operational status can drive visibility in the service map, influence change risk scoring, and filter which CIs appear in reports. Fields that are populated but never updated are worse than empty fields because they create false confidence. If a lifecycle attribute cannot be maintained through discovery, integration, or a defined manual process, it is worth questioning whether it belongs on the record at all.
This is also where enforcement matters as much as design. Defining that a field should exist is only half the work. Ensuring it is populated correctly and stays current is the other half — and that is where many CMDB implementations fall short.
Class-Specific Requirements
Beyond the shared attributes that apply across all CIs, each class in the CMDB has requirements that reflect its specific role in the environment. A server CI needs different fields than a business application or a network switch. Applying a one-size-fits-all attribute set across all classes leads to either bloated records full of irrelevant fields or sparse records missing critical context.
The selection criterion for class-specific attributes is functional relevance: does this field describe something meaningful about this type of CI that supports how it is managed, reported on, or related to other records?
Hardware CIs
For physical infrastructure such as servers and network devices, class-specific attributes often include CPU count, RAM, disk capacity, rack unit position, and data centre location. These fields support capacity planning and physical audit processes. Hardware CIs also frequently carry asset-linked fields that connect the CI record to the corresponding asset record in ServiceNow Asset Management.
Software and Application CIs
For software instances and business applications, relevant class-specific attributes include version number, patch level, hosting model (on-premises or cloud), and the business capability or service they support. In a CSDM-aligned implementation, application CIs typically carry relationships to business services and technical services that depend on them, making the relationship data as important as the attribute data.
Cloud and Virtual CIs
Cloud resources introduce attributes that have no equivalent in physical infrastructure: region, availability zone, instance type, resource group, and subscription or account identifier. These fields are essential for cost allocation, security posture assessment, and cloud governance. Discovery tools can populate many of them automatically, but the data model still needs to define which fields are required and what valid values look like.
Defining class-specific requirements is also where the gap between design and enforcement becomes most visible. It is straightforward to decide that all server CIs should carry an operating system version. It is harder to ensure that every server CI actually does, that the value is current, and that it follows a consistent format. Enforcing those requirements at scale — across thousands of CIs and multiple data sources — is where tooling makes a real difference. We built Data Content Manager specifically to close that gap, giving teams the ability to define data model requirements and enforce them natively within ServiceNow, without scripting or custom development.
If the attribute selection process has surfaced gaps in how your current CI data model is defined or enforced, we are happy to walk through what that looks like in practice. Book a demo to see how we approach CI data quality in real ServiceNow environments.
