OOTB De duplication - Process and Concerns

[pri_mundhra]

I have been playing around with the OOTB de duplication capability and have some concerns that I am not able to get around 

1. Asset relationship transfer: If I have 2 CIs and I want to keep the 1st CI , but the 2nd CI has an asset, how can I transfer the relationship of that asset to the 1st Ci. The OOTB Duplicate remediator does not give me an option to transfer the asset - lets me change the asset tag but not the exact reference.

2. Expense record table - I want to retain those relationships as well, but I don't get an option during the manual remediation process using duplicate remediator

3. We have some custom business rules in place that does not let you edit a task once they are closed, this throws error and the remediation fails, is there a way to bypass business rules using the duplicate remediator? 

Also, what should be a long-term process if we wish to use this tool?

[Vipul Sethi]

ServiceNow has a strict safety gate built into the platform. There is a system property called: "glide.duplicate_ci_remediator.related_items_blacklist"

By default, this blacklist explicitly contains alm_asset.ci and fm_expense_line.ci. This is why the manual tool does not let you transfer the exact asset reference or view the expense lines, the OOTB remediation engine is strictly forbidden from touching them out of the box.
One Potential solution will be to have a custom background utility (triggered via a UI button on the Duplicate Task form or via Flow Designer) prior to running the standard remediator.

The potential script that you will write in UI action or flow should executes the following things:

1. Breaks the 1:1 Loop: It clears the asset reference field on the duplicate CI, updates the ci reference on the Asset table to point to the Master CI, and hooks the Master CI's asset field back to that asset.

2. Syncs Mismatched Data Natively: It invokes new AssetAndCISynchronizer().syncRecords(assetGr, 'cmdb_ci');. This is a critical step; it translates asset financial states to CI operational states and safely activates loop-prevention flags (skip_sync) so your system doesn't trigger infinite update loops.

3. Moves Expenses: It sweeps fm_expense_line, updates the CI reference, and uses .setWorkflow(false) to bypass closed-state validation rules.

After this custom script execution, Your team then processes the duplicate task normally using the standard UI since the asset/expenses have already been cleanly migrated.

[pri_mundhra]

Thank you for the quick solution. 

I have a question regarding the custom script. 

As per the first point, you are saying that, the script should trigger before the whole process- but the first step of the OOTB process is to select the Main Ci- how would we run the script without knowing the main Ci. 

also, how will this work when I use templates?

For the second one, can you explain why this is a critical step- with an example - are you talking about asset state being linked to the ci state - like asset "in use" to operational?