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? 

[asajay011]

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?

[mholmes]

I have also experienced this issue, and don't have a good solution except to remember to search for Change Requests that have an empty Configuration Item field after the de-duplication process, then fix them manually. (Fortunately for us, in the scenario where this most frequently occurs, the changes are created via automation, and include the name of the CI in the short description. We also tend to only have a small number of de-duplications at a time.) The "blanking" of the cmdb_ci field is not even logged in sys_audit, so we can't find the old sys_id by querying sys_audit for cases where the cmdb_ci field's "new value" is blank.

Theoretically, changing the relevant Cascade Delete Rule from "Clear" or "-- None --" (the default is "Clear", which means "Deleting a record clears references") to "None" ("Deleting a record does not change records that reference the record") would at least leave the sys_id of the deleted record as a "dead reference" in the cmdb_ci field of the change request. I'd rather have that than a silently emptied value. I'm not sure if any internal logic in the duplicate remediation process would override this behavior, though.

However, if that worked, you could run a script to look for change requests with sys_ids that don't refer to existing CIs, then query the duplicate_audit_result table for records where duplicate_ci={the sys_id of the deleted CI} (I just confirmed that that reference does remain...perhaps because it's a "Document ID" field instead of a normal reference), then walk up to the reconcile_duplicate_task and query for the other duplicate_audit_result record, grab the sys_id of the "surviving" CI from there, and set it as the CI of the change request. It could even be a scheduled job, or a more "targeted" business rule that triggers upon completion of the Remediate Duplicate Task.

I suppose that if you couldn't, or didn't want to, change the Cascade Delete Rules, you could alternatively write a business rule to look up the change requests associated with each CI at an appropriate point in the Remediate Duplicate Task's lifecycle, and store the  information in a custom field on the task record. Then, when the task completes, execute another Business Rule to repair the change requests previously associated with the deleted CI.

All of these options are a little "involved" as workarounds go, so I am glad to hear that they plan to change the OOB behavior!