Duplicate detection rules in Dynamics CRM are an example of a configuration item that may often be active only in production environments. Since you don’t actively enter data into development or test environments, why bother thinking too much about them? Well, the one place where you need to be thinking about them is when you are importing new solutions and publishing changes to customizations.
Life would be easy if you could just set up and publish your duplicate detection rules once during the initial configuration of your Dynamics CRM production environment, thus stopping the unintentional entry of duplicate records into the customer database. However, you may run into a situation where a rule that you’ve once published has later on returned to an unpublished state. “What? Who touched my duplicate detection settings?”
The likely answer to the question is “You did, but unintentionally”. You see, the duplicate detection rules are sensitive to changes in your entity customizations. As noted in the Madrona Solutions Group blog article, whenever any entity metadata is changed, all duplicate detection rules associated with that entity are unpublished.
If you look at this from the system’s perspective, the process does make sense. After all, you might have set up a duplicate detection rule that is comparing records based on a criteria that that references fields you’ve changed or removed as a part of your CRM customization actions. Still, the fact that a publish event on a CRM 2011 solution triggers an unpublish event somewhere else is not very intuitive and most system administrators are likely to be unaware of the impact. As a result, there are certainly several production CRM environments out there where the once carefully planned duplicate detection rules have been deactivated because of this dependency between solutions and duplicate detection. In fact, you might want to check your own Dynamics CRM environment right now and check if you see duplicate detection rules with the status reason “unpublished” which should in fact be published.
What this means in practice is that anyone who’s deploying solution updates to an environment that is using duplicate detection rules needs to instructed to always re-enable the rules after they’ve updated customizations that reference an entity which is being monitored for duplicates. In my opinion, it would be very practical to have the system notify you about this task, for example by asking “would you like to re-publish the affected duplicate detection rules?” when publishing a solution. If you would like to see this functionality changed in a future version of Dynamics CRM, please sign in to Microsoft Connect with your Windows Live ID and vote for the item “Automatically re-publish duplicate detection rules after deploying a solution”. Thanks for your contribution.
Edit 2013-05-02: There’s a post on Magnetism blog that shows you how to write a plugin that will automatically publish unpublished duplication detection rules after the “publish all customizations” event, in case you want to automate this procedure in your production environment.