Understanding CMDB Dependent CI Deletion Policy in ServiceNow
In any large CMDB, relationships between Configuration Items (CIs) evolve constantly. Services retire, infrastructure changes, and dependencies shift. But what happens when a CI loses all its parent relationships and is left with no logical owner?
ServiceNow handles this through the Dependent CI Deletion Policy — a structured, approval-driven process that ensures no CI is deleted without proper review.
This policy applies specifically to dependent-class CIs — those that only make sense in the context of a parent. When such a CI becomes orphaned, it enters a governed workflow rather than being silently removed.
What is a Dependent CI?
Not every CI in the CMDB is equal. Some CI classes are designed to exist only in relation to a parent — they are dependent CIs. A dependent CI that loses all its parent relationships has no meaningful context in the CMDB is orphaned.
The deletion policy is built specifically to catch these cases.
How it works, step by step
The process begins the moment a relationship between two CIs is removed. A trigger evaluates both the parent and child CI to determine if either belongs to a dependent class. If so, it checks whether that CI now has zero remaining parent CIs. An orphaned dependent CI is the only condition that advances to the next stage.
Qualifying CIs are added to cmdb_dependent_ci_ledger — the staging table for all pending deletion candidates. Each record is stamped with a status of Ready for Deletion and waits here until the scheduled processor picks it up.
A scheduled job — CMDB DependentCI Policy Processor — runs daily at 9:30 AM by default. It reads records from cmdb_dependent_ci_ledger and processes them, clearing each entry as it goes.
4.Task created in cmdb_data_management_task
For each processed CI, a task record is created in cmdb_data_management_task. If the deletion policy is configured with a Task Management Group (as a managed-by group), the system maps the CI's managed-by group to the task's assignment group. When CIs belong to different managed-by groups, separate tasks are created per group — ensuring the right team reviews each CI.
The approval workflow
Once a task is created, it goes to the CI's managed-by group for approval. This is where human judgement enters the process.
First — group member approval
Members of the assigned managed-by group receive the approval request. They review the CIs in scope and make a decision.
The CIs covered by the task are deleted. Their sys_ids are recorded in a text field attached to the task for audit purposes, and the task is closed as Complete.
The default batch size is 1,000 records per run. If your environment has more than 1,000 orphaned CIs to process in a single cycle, you can increase this limit by creating the system property glide.cmdb.data.manager.delete.batch.size and setting it to the required value. Without this property defined, the processor falls back to the 1,000 record default.
The task escalates to users holding the data_manager_admin role for a second round of review.
Second — data manager admin approval (on rejection)
If the group rejects the request, it moves to data_manager_admin role users — the platform's data governance owners. They perform a final review.
Same outcome as the group approval path — the CIs are deleted, their sys_ids logged in the task's text field, and the task closed as Complete.
The default batch size is 1,000 records per run. If your environment has more than 1,000 orphaned CIs to process in a single cycle, you can increase this limit by creating the system property glide.cmdb.data.manager.delete.batch.size and setting it to the required value. Without this property defined, the processor falls back to the 1,000 record default.
The task is closed Cancelled, No CIs are deleted. The record is preserved for audit.
Key tables and components
| cmdb_dependent_ci_ledger | Staging table for orphaned CIs pending deletion review |
| cmdb_data_management_task | Task record created per CI group for approval routing |
| CMDB DependentCI Policy Processor | Scheduled job — runs daily at 9:30 AM, processes ledger records |
| glide.cmdb.data.manager.delete.batch.size | Controls records processed per job run. Default is 1,000. Create this property and set a higher value if your volume exceeds 1,000 records per cycle. |
| Task Management Group | Optional policy config — maps CI managed-by group to task assignment group |
| data_manager_admin | Fallback approver role when group-level approval is rejected |
Why this matters?
Orphaned CIs are a major contributor to CMDB clutter. When not addressed, they can disrupt service dependency maps, overstate asset counts, and create challenges during incident and change management. The Dependent CI Deletion Policy gives organisations a repeatable, auditable way to keep the CMDB clean — without risking accidental deletion of CIs that might still be in use.
The two-tier approval model (managed-by group first, data manager admins second) ensures that the people closest to the CI have the first say, while a governance backstop exists if they push back. Every deletion is traceable through the task record and the sys_id log attached to it.
For teams configuring this for the first time: start by reviewing your dependent CI classes, ensure managed-by groups are populated accurately on your CIs, and validate the Task Management Group setting on your policy before running the processor job.
