CI is not getting retired via CMDB Data Manager in Development Instance but in QA instance.

[Piyush Dwivedi]

Network Adapter CI is not getting retired via CMDB Data Manager in Development Instance but getting Retired in QA Instance.

I have created a Retirement definition then created a Policy after that i have executed Scheduled job...It works perfectly fine in QA Instance but not in Development Instance.

Is there a Known issue?

[Pratiksha]

Share both the screenshots. 

[AJ-TechTrek]

Hi @Piyush Dwivedi ,

1 – First: There’s No General “Known Issue”
There isn’t a broadly acknowledged ServiceNow defect where CMDB Data Manager retirement works in one instance and fails in another for the same CI type, so this is almost always instance-specific configuration or data differences.

2 – Key Things to Check

A. Retirement Definition Scope
* Open the Retirement Definition in Dev and QA.
* Confirm:
* The Table/Class is exactly the same (cmdb_ci_network_adapter).
* Filter conditions match.
* The definition is Published.
* Make sure the definition is not restricted to a domain if you use Domain Separation.

B. CMDB Data Manager Policy
* Ensure the Policy in Dev is:
* Linked to the correct Retirement Definition.
* Active and Published.
* Not restricted by additional conditions that might filter out your CIs.

C. CI Data Differences
* The retirement process only targets CIs matching the definition’s filter.
* Check that the Network Adapter CIs in Dev actually meet those filter conditions (status, discovery source, last discovered date, etc.).
* In QA, maybe the test CIs meet the conditions — in Dev they might not.

D. Scheduled Job Execution
* Check if the CMDB Data Manager Scheduled Job (cmdb_data_manager_process) actually ran in Dev at the expected time.
* Review System Logs for any errors during execution.
* Compare the execution logs in Dev vs QA:
* System Logs → All → filter by source = cmdb_data_manager

E. Roles & Permissions
* The System user running Data Manager needs cmdb_admin and other CMDB-related permissions.
* In non-prod, sometimes roles are accidentally removed from the system user or MID server accounts.

F. Plugin or Configuration Mismatch
* Make sure the CMDB Data Manager plugin is at the same version in Dev and QA.
* Check System Definition → Tables & Columns to ensure install_status values for Network Adapter CIs are identical across environments.

3 – How to Test Quickly
1. In Dev, open your Retirement Definition.
2. Click Preview → see if any CIs are listed.
* If zero results, the filter is too strict or data is missing.
3. If results show → Run the Policy manually in Dev and check logs.
4. If still no change → turn on Debug Logging for com.snc.cmdb.data_manager and re-run to see why each CI was skipped.

4 – Common Causes I’ve Seen
* Filter mismatch: e.g., install_status=Installed in Dev but CIs are In Use.
* Discovery source mismatch: Dev CIs may have “Manual Entry” while QA CIs have “Discovery”.
* Inactive Policy in Dev.
* Job not running because the schedule isn’t active in Dev.
* Domain separation filter excluding Dev CIs.

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