Policy-driven lifecycle is different from bulk housekeeping
A CMDB can be weakened by retaining every stale record forever, but bulk deletion without ownership can be worse. CMDB Data Manager provides policy-driven lifecycle actions such as attestation, certification, retirement, archive and deletion within supported class and configuration constraints. An implementer chooses the right policy to achieve the intended outcome and validates which CIs meet its conditions; the purpose is not to automate every “old record” away.
The ServiceNow Data Manager documentation describes those policies and dependent-CI handling. Policies target classes extending the supported cmdb_ci hierarchy. Destructive actions are not interchangeable with confirming an owner or updating a lifecycle stage. Selecting a policy without checking class retirement definitions, approvals and dependencies can cause business-impacting data loss.
A fictional bank has thousands of retired test VMs, hundreds of active branch devices and a manually maintained payment application. Their refresh cadences and data value differ. A single delete-if-not-updated rule across all three would conflate transient infrastructure, long-lived hardware and business meaning. Governance defines the population and approval workflow first.
Use attestation to validate ownership and business facts
Attestation seeks human confirmation or correction of attributes and records from the appropriate steward. A technical discovery feed may know a machine is online but cannot decide whether a business-unit owner remains correct. An attestation task can route that decision to someone accountable and retain evidence of their response.
Before publishing a policy, decide the target class, eligible records, reviewer identity, review cadence and what happens if the reviewer does not respond. A missing Managed by Group may route work unexpectedly or leave ownership unclear. Avoid creating mass tasks for teams that cannot reasonably validate the records; segment by service, class and criticality.
An attestation is not an end-to-end health measurement. The reviewer may confirm owner and lifecycle attributes while an automated correctness check still detects a duplicate identifier. Use separate controls for unique identity, source freshness and human-confirmed semantics.
Understand the distinct retire, archive, and delete goals
Retire marks a CI as no longer active under the supported lifecycle model; it may remain referenced for history. Archive moves eligible retired data into a retained archival state or store according to configured behavior. Delete removes eligible records and therefore requires the strongest analysis of references, retention and recovery. The right sequence and prerequisites depend on the policy, targeted class and instance configuration.
ServiceNow policy creation guidance notes that lifecycle policies for retire, archive and delete require an active retirement definition for applicable classes. Archive/delete processors target already retired CIs according to documented rules. A policy that fails due to missing definitions is not resolved by bypassing the lifecycle using an unguarded table delete.
For a lab class, retire a test CI only after proving it is genuinely out of service and evaluating dependent records. After the retention period, an archive may preserve necessary context. Deletion is appropriate only after policy, business approval and downstream reference analysis agree it is safe. Never treat a sandbox example as authorization for mass production cleanup.
Dependent CI management creates an additional review step
CIs have relationships. A retired host can contain adapters, processes or attached components that become orphaned; it may also be associated with an application service still in use elsewhere. Cascading lifecycle actions must distinguish dependent objects that cannot exist meaningfully without their parent from valid objects that should remain. Relationship type and direction matter more than the number of connected records.
A migration scenario demonstrates the risk. An old server is decommissioned, but its application service moves to a new host. A blind cascade-delete from the old host could erase valid service context. The correct process updates the application-service hosting relationships first, confirms the service is healthy and then handles obsolete dependent CIs according to supported rules.
Data Manager can generate approval or lifecycle tasks for dependent CIs. Build a decision record for primary CI, affected descendants, unrelated associations and any manual exceptions. This makes an automated outcome auditable instead of surprising the service owner after the records disappear.
Build a safe policy rollout and monitoring routine
Use a narrow eligible population first. Capture filter, class, lifecycle rule, owner, excluded CIs, anticipated count and evidence for the business decision. Preview or inspect targeted records using supported workspace capabilities before activation, and confirm that the processor and task assignment operate as intended. A policy labeled “attest” is not proof that recipients completed their reviews.
The Data Manager components reference describes scheduled processors and dependent lifecycle information. Operational teams should monitor job outcomes, exceptions, stale tasks and blocked approvals. If the workflow repeatedly targets records that should not be retired, fix the filter and source of lifecycle evidence before increasing the deletion rate.
Version policy changes with dates and approvals. A new cloud fleet or inventory integration can radically change which CIs match a stale criterion. After each meaningful change, compare actual target counts to expectations and check whether critical services remain present in queries and incident forms.
Pair lifecycle policy with CMDB Health and governance
CMDB Health exposes staleness and orphan metrics; those scores are investigation signals, not blanket permission to remove data. The governance and duplicate-remediation process supplies ownership and adjudication. A stale CI might be a genuinely retired host or a live host whose discovery feed stopped reporting. The correct policy outcome depends on which hypothesis the evidence supports.
Use two contrasting cases: a six-month-old ephemeral container whose authoritative cloud inventory confirms deletion, and an on-premises device that has not been scanned because a collector failed. A destructive policy may be justified for the first after safeguards, but would conceal the monitoring failure in the second. Neither case can be decided from a last-updated timestamp alone.
A healthy lifecycle program knows which CIs to keep, which need attestation, which can retire and which may be archived or removed under accountable rules. Fewer rows in a dashboard are not success unless the remaining configuration model better reflects operational reality.
Compare policy choices using identical starting data
Suppose a retired test CI has not refreshed for 120 days. An attestation policy might ask its owner whether it is still relevant. A retire policy is unnecessary if the item is already correctly retired. Archive may be appropriate after the required history-retention period; delete requires authorization and supported prerequisites. These options produce different operational and audit outcomes even though all are described casually as “cleaning up old CIs.”
For a second CI that was last seen 120 days ago but whose host is still running, a retire rule would be inappropriate. The immediate task is to repair monitoring or discovery. Record a source-freshness incident and verify the host rather than using Data Manager to make the stale alert disappear. An automated age predicate is a signal requiring business and technical context.
For a third CI that has dependent child records, a policy must account for whether those children are still meaningful and how the platform processes dependencies. Retiring a parent without understanding related services can leave inaccurate impact maps; cascading deletion can remove valid history. Review source relationships and approvals before scheduling.
Keep policy versions and audit outcomes explainable
A lifecycle policy that works for temporary cloud containers may be dangerous when its class scope expands to persistent servers. Every material policy change should have a version, owner, change reason, expected target population and exception review. After publication, compare actual generated tasks or processed records with that expectation. A count mismatch is a reason to investigate, not a target to hit by loosening filters.
When a previously active class receives a new retirement definition, test on representative retired and live CIs. Ensure the definition uses the actual lifecycle semantics of the class, and that archive and delete processors do not unexpectedly target unrelated records. Operational safety rests on the selection predicate and dependencies, not on the policy title.