The twists of duplicate detection

By | January 23, 2019

 

There is an interesting twist with the duplicate detection in Dynamics which kind of makes sense once you realize this is how it works, but it may not be obvious at first.

image

Imagine that you have duplicate detection rules configured for a certain entity, and most of your users have business-unit access to that entity. Which means that, in reality, those duplicate detection rules will normally work within each business unit, but somebody having organization-wide permissions will still see duplicates (when those duplicates are created in different business units).

Then imagine that you need to load the same set of data into two different business units. You would think it’s easy – log in as a system administrator, use excel import, and, while importing, assign newly imported records to a team (or to a user) in the target business unit.

That’s the assumption I made the other day, and it turned out to be a wrong one. When running the import, Dynamics will look for the duplicates first, and it will do the assignment only after that. So, as a system admin, I’ll only be able to import those records into one business unit, and, then, while trying to import into another one, I’ll start getting duplicate detection errors.

Fine, you may say.. so why don’t we add a “match” condition for the owning business unit to each of the duplicate detection rules involved in this process?

image

This is another interesting one. If we do this, it seems that duplicate detection rules just stop working at all. You don’t need to run a data import to test this – the rules will stop working even for the records you’ll be creating manually. Why?

Honestly, I am not sure, but, from my vague recollection of how the data is populated behind the scene, I think “Owning Business Unit” field is not populated immediately  on create of the record (it’s kind of a calculated field.. Once a record is assigned to an owner, Dynamics will look at that owner record to calculate the value of the business unit field)

What’s the solution, then? It seems the only way to make it work in the above scenario is to create a user account, to put that user account into the destination business unit, to import the records under that user account, and to remember to assign newly imported records to a different team or user in that business unit(without the last step, which can be done as part of the import, all those imported records will keep following the user account to other business units). Once it’s done, we can move that user account to a different business unit and repeat the process.

Leave a Reply

Your email address will not be published.