CMDB De-duplication remediation issue with Change tickets

[Catherine Proco]

We have an issue when we run a de-duplication task on a CI that has been added to a change ticket. After the de-duplication task is completed, the CI that was previously added to the Change ticket is now gone. Are we missing a step in our remediation to ensure that configuration items that have been added to a Change ticket are not getting removed? 

[AJ-TechTrek]

Hi @Catherine Proco ,

As per my understanding why It Happens

* When you run a de-duplication task, the duplicate CI record is merged into the "master" CI.
* Relationships, incidents, and other references are supposed to be moved to the surviving CI.
* However, if Change Request CI references (task_ci table) are not explicitly remediated during merge, the reference to the duplicate CI gets deleted instead of re-pointed.
* This leads to the CI disappearing from the Change record.

Below Solution Approaches might be helpful for you.

1. Check De-duplication Remediation Settings
* Go to CMDB De-duplication > Remediation Definitions.
* Ensure the task_ci table (CI references for Change/Incident/Problem/etc.) is included in the remediation definition for your CI class.
* If it’s not included, add it, so when a merge happens, all Change-related CI references get re-pointed to the surviving CI.

2. Use IRE and CI Merge Rule Properly
* Ensure your de-duplication process is using IRE (Identification & Reconciliation Engine) rules, not only direct delete/merge.
* IRE rules can be configured to move relationships and task references to the surviving CI.
* This avoids “orphaned” Change records with missing CIs.

3. Custom Post-Merge Script (if needed) ( I am not so much good in Scripting Part)
* If Change CI references (task_ci) are not handled automatically, add a post-merge business rule or script to re-map them.


(function executeMerge(duplicateCI, survivingCI) {
 var taskCI = new GlideRecord('task_ci');
 taskCI.addQuery('ci_item', duplicateCI);
 taskCI.query();
while (taskCI.next()) {
 taskCI.ci_item = survivingCI;
taskCI.update();
 }
})(duplicateSysId, survivingSysId);

* This ensures all Change, Incident, Problem, etc. records remain intact with the new surviving CI.

4. Governance Best Practice
* Before running bulk deduplication:
* Communicate with Change/ITSM teams.
* Run the impact preview to see what references will be touched.
* Test on a subset in sub-prod.
* After merge: validate that Change records still show their 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

[Cindy Trieu]

Hi Catherine,

Do you also want to preserve and keep the duplicate CI's in addition to the tasks?

If so, under the "Duplicate CI Action" section, make sure to select the option to update fields instead of delete. You can set operational status to retired for example or the state to appropriate state. If you do this, it is recommended to also add identification inclusion rule so we don't reprocess these CI's in the future. I would try it on a subprod or test instance first. Here is the documentation for that: https://www.servicenow.com/docs/bundle/zurich-servicenow-platform/page/product/configuration-managem...

You can afterwards create a data policy to archive these CIs. I believe they'll still be linked in the change request and their data will be preserved, but they will no longer be in the CMDB table, so you will have more accurate data there. Here is the documentation for Data Manager policies: https://www.servicenow.com/docs/bundle/zurich-servicenow-platform/page/product/configuration-managem...

The data manager policy portion is just a recommendation, it is not necessary for resolving your issue. The identification inclusion rule may be necessary, depending on your data set up and how you resolve the duplicate CI's.

[Catherine Proco]

Thank you everyone. We did set up our default to ensure that change tickets, tasks and affected CIs are in our default list. However, when we look at the related list, they always show as 0, unless the Change ticket is in a New state. We want to delete the CI that is not the main ci - but this removes the CI from the Task_ci table. ServiceNow says this is normal behavior as it follows the BR of Change:Prevent update of CI if not New. However, even if we turn that BR off, the de-duplication process works the same and ignores changes that are not new and does not merge change ticket affected CI's - leaving the Change ticket without an affected CI. ServiceNow told us this is expected behavior and they are working on a fix that will be available in 2 releases. We have been told we are the only ones that have experienced this issue and their work around is to create either a custom field or custom lifecycle status, not delete the CI and then run a custom process after the remediation is complete to update the task_ci table with the correct(main) ci and then delete the CI that should have been deleted during the de-dup process. Does anyone else have this issue and is using this workaround or have found a more elegant solution?