Retrying a failed Duplicate CI Remediation Task can remove CIs from locked Change records

[Greg Hoschar]

We have been remediating a large number of Duplicate CIs created by a flawed integration. Many of them failed with the following error:

Error updating related entry CIs Affected [task_ci] -> Configuration Item:
Operation against file 'task_ci' was aborted by Business Rule 'Change: Prevent update of CI if not new^{sys_id of the triggering task_ci record}'. Business Rule Stack:Change: Prevent update of CI if not new

The referenced business rule prevents the Configuration Item and CIs Affected from being modified on any Change Request after it has been submitted (a valuable, though frequently inconvenient rule.)

This ultimately leaves the DUP Task in a "Pending" state. Every Pending DUP task in our instance is caused by this business rule.

The real problem shows up later, when I try again to remediate the Pending DUP task again. I specifically select the CI on the the change record that halted the previous run as the Main CI in the Duplicate CI Remediation wizard and attempt to merge the other CIs into that one.

If there is a locked Change affecting one of the other duplicate CIs, I would expect the attempt to fail again and remain "Pending". In some cases, it instead deletes the CI from the Change Request and the CIs Affected [task_ci] record even though that business rule should block any such modification. CI is a required field on Change requests in our instance, so this locks up the Change record. Nothing short of an admin deleting the Change record can alter it from that state.

Can anyone explain why the business rule fails on the second attempt? I've verified that a Pending task continues to fail in exactly the same way if you select the same Main CI on the second attempt that you leveraged the first time. Switching the Main CI seems to be required for this situation to occur.

Does anyone know where the Duplicate CI Remediation wizard is defined? if I can step through the code,  I may be able to make sense of what is happening

[emir]

Take a look at this KB here: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0759319

I suggest you work with support to look into the details

[Greg Hoschar]

Thank you, Emir.

I eagerly await the future enhancement described in the Workaround section of the page you linked.

I've also opened a case with ServiceNow.