Issue with Cascade-Archive of Dependent CIs Not Archiving Children

Willie · 4 weeks ago

Hi everyone,

I'm working on implementing the cascade-archive dependent CIs functionality in ServiceNow CMDB, but I'm running into an issue where child CIs are not getting archived as expected. Here's the sequence of steps I'm following:

🧩 Steps Taken:

Run Scheduled Script Execution: CMDB Data Manager Retire Policy Processor
- This picks up the retire policy and sets the base CI (bob1) to Life Cycle Stage = End of Life.
- This triggers the OOTB business rule Track "Retired" CIs, which adds the CI to cmdb_ci_end_of_life_ledger.
- It also evaluates dependent relationships to populate the ledger.
Run Scheduled Script Execution: CMDB Cascade Retire Dependent CIs
- This adds dependent CIs to the cmdb_dependent_ci_ledger.
- Note: Child CIs must match a retirement definition to be eligible for archival.
Run Scheduled Script Execution: CMDB DependentCI Policy Processor
- This should apply the cascade-retire workflow to dependent CIs listed in the ledger.
Archive the base CI (bob1) using CMDB Data Manager Archive/Delete Policy Processor
- A CMDB Data Manager Task is generated.
- An archival chunk is created and executed.
- The base CI is moved to ar_cmdb_ci_computer.
Post-Archival Observation:
- Relationships in cmdb_rel_ci are now orphaned.
Re-run: CMDB DependentCI Policy Processor to invoke Dependent CI Archival
- Still, child CIs are not archived.

🔍What I’ve Checked:

Retirement definitions exist for child CI classes.
Archival policies are active and applicable.
Relationships were valid before archival.
Child CIs are not appearing in cmdb_dependent_ci_ledger.

❓Question:

Has anyone encountered this issue where child CIs are not archived during cascade-archive, even though the parent CI is successfully archived?

Any insights or suggestions would be greatly appreciated!

Thanks in advance 🙏

Willie · 3 weeks ago

I figured it out. To add an action = 'archive' for the child CIs, you must ensure that the CI Class that you want to cascade is not independent based on cmdb_identifier.

View solution in original post

AJ-TechTrek · 3 weeks ago

Hi @Willie ,

Thanks for sharing the document and the detailed sequence. Based on your steps and the references from ServiceNow’s Cascade-Archive documentation and KB article , here’s why your child CIs aren’t being archived and how to fix it.

As per my understanding why It’s Happening

1. Retirement Definition Coverage Even though you have retirement definitions for child classes, the Cascade Retire process only includes CIs in cmdb_dependent_ci_ledger if they strictly match a retirement definition and a relationship rule. If your child class isn’t meeting both, it won’t show up.

2. Ledger Population Issue You mentioned child CIs never appear in cmdb_dependent_ci_ledger. That means they are being skipped before archival. Most often this is due to
* Missing or misconfigured Dependent Relationship Rules.
* The parent CI being archived before children are processed (once archived, relationships become orphaned and children are no longer linked).

3. Policy Execution Timing The cmdb_dependent_ci_policy_processor doesn’t archive or retire immediately. The documentation clarifies “orphan dependent CIs are not immediately archived — they are evaluated eventually.” This means you need to ensure your archival policy includes a Dependent CI Archival subflow to kick in after orphaning.

4. Manual Restore Side Effect Since you manually restored a CI from archive (933d0e1283d7e2100830c5b5eeaad3de), it likely skipped the cascade process because Data Manager tracks state transitions. If the CI bypassed the normal lifecycle, it won’t be picked up.

Recommended Solution
1. Verify Dependent Relationship Rules
* Navigate to CMDB Data Manager > Dependent Relationship Rules.
* Ensure your child CI classes (e.g., servers, components, etc.) have rules linking them to the parent class (Depends on, Hosted on, etc.).
* Without a valid rule, Cascade Retire Dependent CIs won’t populate cmdb_dependent_ci_ledger.

2. Confirm Retirement Definitions
* For every child CI class, make sure an active retirement definition exists.
* Run a quick query on cmdb_retirement_definition for those classes and confirm they’re not restricted by conditions.

3. Rerun Jobs in Correct Order
* Run:
1. CMDB Data Manager Retire Policy Processor (base CI retired)
2. CMDB Cascade Retire Dependent CIs (child ledger population)
3. CMDB DependentCI Policy Processor (cascade-retire workflow)
4. CMDB Data Manager Archive/Delete Policy Processor (archive tasks)
* Ensure step 2 succeeds before step 4, otherwise children will be orphaned.

4. Check cmdb_dependent_ci_ledger
* After running step 2, confirm child CIs appear here with action = “Archive.”
* If not, the relationship rules are the root cause.

5. Final Cleanup (if needed)
* If children were orphaned already, use Cleanup Orphan CIs scheduled job (OOB) to handle them.
* Or re-establish relationships temporarily, rerun cascade, and then archive.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

Willie · 3 weeks ago

I suspect this response is AI generated. Can someone from SN chime in?

Willie · 3 weeks ago

I figured it out. To add an action = 'archive' for the child CIs, you must ensure that the CI Class that you want to cascade is not independent based on cmdb_identifier.