Every configuration item in ServiceNow has a story. It begins when a server is provisioned, a laptop is purchased, or a software license is assigned. It ends when that asset is decommissioned and removed from active management. What happens in between, the CI lifecycle, determines whether your CMDB reflects reality or slowly drifts into a state that no one fully trusts.
Understanding the CI lifecycle is foundational to reliable ServiceNow CMDB management. When lifecycle stages are well-defined and consistently enforced, teams can make confident decisions about incidents, changes, and asset spend. When they are not, the CMDB becomes a source of confusion rather than clarity. This article walks through each stage of the configuration item lifecycle, the status fields that track it, who owns what at each point, and how retirement and archival should be handled.
CI Lifecycle Stages
The CI lifecycle describes the full journey a configuration item travels from the moment it enters your environment to the moment it is removed from active use. ServiceNow models this as a series of distinct stages, each representing a meaningful operational state.
A typical CI lifecycle moves through the following stages:
- Planning / On Order: The CI has been requested or approved but has not yet been received or deployed. It exists in the CMDB as a record so procurement and change processes can begin tracking it early.
- In Stock / In Maintenance: The CI has been received or is undergoing preparation, testing, or repair before being placed into active use.
- Deployed / In Use: The CI is live and actively supporting business operations. This is the primary operational state and where most CMDB activity occurs.
- Retired: The CI has been decommissioned and is no longer in active use. The record is preserved for audit, historical reference, and reporting purposes.
To make this concrete: consider a physical server. It enters the CMDB during procurement with a status of “On Order.” Once it arrives and is configured, it moves to “In Stock.” When it is deployed to a data center and begins serving workloads, it transitions to “Deployed.” Years later, when it is replaced and powered down, it is marked “Retired.” Each transition should be deliberate, documented, and tied to a process, not a manual edit made by whoever happens to notice the hardware is gone.
The challenge most organizations face is that these transitions are not always enforced. Records linger in “Deployed” long after hardware has been removed. New CIs are added without going through the early stages. The lifecycle becomes aspirational rather than operational.
Status Fields
ServiceNow tracks CI lifecycle position primarily through the Install Status field on the Configuration Item table. This field drives much of the CMDB’s operational logic and feeds into reporting, discovery reconciliation, and compliance checks.
The default Install Status values in ServiceNow include options such as “Installed,” “In Stock,” “On Order,” “Retired,” and “Stolen.” These map broadly to the lifecycle stages described above, though organizations often extend or relabel them to match internal terminology. A company might add a custom “Pending Decommission” status to create a formal review gate before a CI is marked Retired.
Operational Status and Additional Fields
Install Status is not the only field that matters. Operational Status captures whether the CI is currently functional and available, independent of where it sits in its lifecycle. A CI can be “Installed” but “Non-Operational” if it is undergoing an outage. Both fields together give a more complete picture of the CI’s actual state.
Other relevant fields include Discovery Source, which indicates how the CI was identified or last updated, and Last Discovered, which shows when an automated tool last confirmed the CI’s existence. When these fields are inconsistent with Install Status, for example, a CI marked “Deployed” that has not been discovered in six months, that is a signal worth investigating.
Keeping these fields accurate and synchronized is where many CMDB programs struggle. Without a mechanism to validate field combinations and flag anomalies, status fields become decorative rather than functional.
Ownership at Each Stage
Clear ownership is what keeps the CI lifecycle from becoming everyone’s problem and no one’s responsibility. Different teams typically hold accountability at different points in the lifecycle, and the handoffs between them are where records most often go stale.
A practical ownership model looks something like this:
- Planning / On Order: Procurement or IT Asset Management owns the record. They are responsible for creating the CI, populating foundational attributes, and confirming receipt.
- In Stock / In Maintenance: The infrastructure or operations team takes over as the CI is prepared for deployment. They validate technical attributes and ensure the record is accurate before go-live.
- Deployed / In Use: A designated CI owner or application owner carries ongoing responsibility. This includes keeping relationship data current, confirming the CI during periodic audits, and initiating the decommission process when the CI is no longer needed.
- Retired: The CMDB team or a data governance function confirms the retirement is complete, ensures no active relationships remain, and archives the record appropriately.
The Managed By and Owned By fields in ServiceNow are the primary mechanism for recording this accountability. When these fields are populated consistently, it becomes straightforward to notify the right person when a CI’s status needs to change or when a discrepancy is detected. When they are empty or outdated, lifecycle transitions depend on someone noticing a problem and knowing who to contact, which rarely happens reliably at scale.
Ownership also matters for AI-driven processes. ServiceNow’s AI capabilities rely on well-attributed CI data to generate accurate recommendations and automate decisions. A CI with no owner and an ambiguous status is a gap in the data that AI agents cannot bridge on their own.
Retirement and Archival
Retiring a CI is not simply a matter of changing a status field. Done properly, it is a structured process that protects data integrity, satisfies audit requirements, and prevents retired records from polluting active CMDB views.
The retirement process should include several deliberate steps before a CI is marked Retired:
- Confirm decommission intent: A change request or formal decommission workflow should trigger the retirement process, not an ad hoc field update.
- Review active relationships: Check whether the CI is still referenced by active incidents, problems, changes, or service dependencies. Retiring a CI that is still mapped as a component of a live service creates gaps in impact analysis.
- Remove or update relationships: Relationships that no longer reflect reality should be ended or reclassified before the CI is retired.
- Update the record: Set Install Status to “Retired,” update Operational Status, clear or archive the Managed By and Owned By fields as appropriate, and document the retirement date.
- Retain for audit: Retired CIs should remain in the CMDB for a defined retention period. They provide historical context for incident reviews, compliance audits, and cost analysis.
Archival is the next step beyond retirement. Some organizations move retired CIs to a separate archive table or apply filters that exclude them from standard CMDB views, keeping the active dataset clean without destroying historical records. ServiceNow supports this through scoped views, table partitioning, and lifecycle-aware reporting.
One of the most common data quality issues we see in ServiceNow environments is a large population of CIs that should have been retired years ago but remain in an active status. These ghost records inflate CMDB counts, confuse discovery reconciliation, and undermine confidence in the data. Addressing this requires both a cleanup effort and a process change to ensure future retirements happen on time.
Enforcing lifecycle discipline across the full journey from procurement to retirement is where tools like Data Content Manager add genuine value. Rather than relying on manual checks or custom scripts to validate CI states and flag anomalies, DCM lets teams define lifecycle rules natively in ServiceNow and surface violations automatically. It is the difference between discovering a problem during an audit and catching it the moment it occurs.
If CI lifecycle management is something your team is working to improve, we are happy to walk through what that looks like in practice. Book a demo to see how DCM supports end-to-end lifecycle enforcement directly within your ServiceNow instance.
