Auto Deletion of CI from CMDB

[baba]

Hi ServiceNow family.
CMDB data in all the 3 instances (Dev/Test/Prod) are not same. I am checking whether there are any settings/scripts which are running periodically and deleting Cis in CMDB and analyzing the settings / Scripts running / Scheduled Jobs to identify if someone/something is deleting CI or not. I checked Data manager Deletion policies, Audit deleted records table, schedule jobs.  Please advise if any important settings / Scripts running / Scheduled Jobs i need to check?

[CasperJT]

Hi baba,

Did you also check archival jobs as well? Archived CI's will not appear in your CMDB, but in separate archive tables.

Are your sources the same? I would assume that you are not running the same integrations continueosly across Dev/Test/Prod towards the same source systems.

Are there CI's being manually maintained in Prod, which would not be present in subprod environments unless cloned?

Perhaps you have filters on your system clone preventing all CI's from being cloned from prod to subprod.

Just some ideas.

Hope this helps.

//Casper

[baba]

hi @CasperJT   Thanks for responding. 1) no i have not checked the archival Jobs yet. can you please let know which job to check and which are separate tables.?

2) Yes sources are same. but in Prod SCCM and Tanium integration discovery sources are present, but they have stopped few months ago. In Dev/Test sccm and Tanium discovery sources are not there.

3) yes Few Manual update is happening in prod via import sets.

4) yes thats right, might be filters unchecked during the clone from prod to subprod. could you let me know what those filter could be? were those filters could be related to CMDB unchecked?

[CasperJT]

Hi baba,

1) The archival jobs are also configured as policies in the CMDB Data Manager. You can reference the docs for more details:

Working with CMDB Data Manager • Yokohama ServiceNow AI Platform Capabilities • Docs | ServiceNow

Archive Use to remove a CI from its current table and store the CI in a separate archive table for temporary retention. Archiving a CI excludes the CI from views and from features such as maps and the relations formatter. During the retention period, you can restore CIs into active state. At the end of the retention period, archived CIs are deleted from their archive table.

2) If your Tanium and SCCM integrations are only active in prod, I would assume you would have more data in prod that lower tier environments onve time.

3) That would also offset data over time

4) I do not think there is anything out of the box excluding CMDB data from your clones, so you would need to check your clone profile to see if it has any exclusion records related to CMDB.

//Casper

[fknell]

Hi, @baba 

worth to mention, CMDB Data Manager provides a policy‑driven framework to retire, archive, and delete CIs in bulk, rather than removing them ad‑hoc.

Retire

- Use a Retire policy to mark CIs as “End of Life” while keeping them active in views and CMDB Health.

- This is the first step before archiving or deleting.

Archive

- Use an Archive policy to move retired CIs to an archive table; they disappear from maps, relations, and most views but can be restored within a defined retention period (up to 10 years).

Delete

- Use a Delete policy to permanently remove CIs from the CMDB with no option to restore.

Best practice is to retire first, then archive, and finally delete after a retention period, and to always align policies with your organization’s data‑retention rules.

Hope this helps.