Problem with de-duplication remediation

[Catherine Proco]

During our de-duplication process, we have set up our default related list to ensure that change tickets, tasks and affected CIs are in our default list. However, when we look at the related list during a remediation, 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(ie next summer). 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 to set on the non main CI, 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? Are we the only ones that feel the de-duplication is not working properly?

[Its_Azar]

Hi there @Catherine Proco 

 

 What you’re seeing is tied to the Change: Prevent update of CI if not New BR, and even disabling it doesn’t fully help because the dedup engine itself skips merging CIs linked to non-New changes. That’s why your related lists show 0 during remediation. 

Most folks I’ve seen either go with the workaround you mentioned (mark the duplicate CI with a custom flag/status, don’t delete it, then post-process task_ci to point to the main CI), or they build a small custom job to handle the reassociation after remediation. Not elegant, but it prevents losing CI references on open changes.

Hope this helps,

[Catherine Proco]

Thank you. To me, this is a problem with the de-duplication process itself and should be fixed. According to ServiceNow, we are the only ones that have an issue with how the de-duplication process works with the change tickets. I find this hard to believe that noone else has an issue and is okay with needing to create a custom process to do what the de-duplication remediation should do out of the box.

[TrevorM57336382]

I'm having this issue too. It doesn't happen every time, which is strange. My workaround is to manually go to each task and update the CI in the form. If that's not an option, disable the business rule and update the CI in the task and then reenable the business rule. It is surprising the duplicate remediator doesn't override this business rule.