Deletion of De-Duplication tasks

[Siva Boppana1]

We have 30K de-duplication tasks. There are 5 years old records too in the list.

We started a CMDB clean up process and planning to delete all these tasks, So new de-duplication tasks will be created if there are any duplicates in the CMDB.

Is there any downside to consider before deleting these tasks.

[Afsar2]

Thanks @DaveHertel ,

This makes sense for now.

Correct me if I am wrong

As per IRE Lifecycle 

I understood the fact that when CIs are inserted through IRE and based on the Identifier rules if any CI exists then dups are created.

But as Identifier helps to prevent duplicates, isn't the Identifier rules are suppose to update the CI record instead of inserting duplicate CI record and creating De-Dup Tasks?

Please advice on this.

[DaveHertel]

Yes, you are correct.  The intention of the IRE identifier rules it to help match existing CIs, and avoid creating duplicates.  But there are many variations on how customers get CI's in the the CMDB.  Not all integrations/solutions use the IRE rules.. they bypass them... which can allow duplicates to occur.   SNOW recommends all integrations should be designed to use the IRE... but that doesnt' mean they do.   Or humans can create duplicates by mistake, etc.  there are various ways duplicates can leak into the CMDB.  Using the IRE/rules/engine wherever possible is strongly recommended.. but its not fool proof... duplicate CI's tend to occur regardless of the best made plans 🙂 

[Siva Boppana1]

Thanks for your reply Sai and Dave.

I have tried the deletion in Dev instance, which was cloned recently.

Now after few days we can see only ~270 de-duplication tasks created in Dev which are mostly of cluster, print queue classes, which I think can be remediated manually and also not of much worry when looked at those class types.

Before Deletion of the de-duplication tasks, YES, we have made sure to understand the root cause for the hardware class mostly, and it was due to an integration source and have corrected it and deleted those CI's which are wrongly inserted or duplicated (~5K numbers). (now the duplicate records are not being created by integration job)

So the original question or the worry was, is that ok to delete the de-duplication tasks and are there any risks/ process flaws associated which I haven't considered.

But as the root cause for hardware type is rectified and other tasks were created many years back where most of those CI's itself are not active in CMDB now.

So we think we can proceed to delete the de-duplication tasks in prod and continue to remediate manually for the ones that gets created from now on.

Please post your views if you think otherwise or any other pointers we are missing.

Thanks.

[doug_schulze]

In my humblest...Yes when you are starting with De-dup tasks and are overwhelmed deleting them might be an easy fix but it still leaves you with duplicates in your CMDB that might not be caught again. So take mind of that. Going forward you might choose to filter/delete non-primary classes and figure out the cause of the result, <insert @DaveHertel 's reply>. After you get things in order you can consider stopping the creation of the de-dup tasks on non-critical classes by excluding them in the ci class manager.

[chandan_nagbans]

Hello Doug,

Could you please assist how can we use CI Class Manager to Exclude non critical Classes to create de-dup tasks. I was looking for some option into the CI Class Manager to exclude any class but I didn't find any. If you could guide me how to do that, it would be much appreciated.