Setting up duplicate detection when integrating data between Dynamics CRM and Dynamics ERP
We’ve seen a few questions come in on the topic of duplicate checking, so wanted to make sure all of you had the info on how this feature is supported with Connector for Microsoft Dynamics.
Before you integrate your Microsoft Dynamics ERP and Microsoft Dynamics CRM, you may have duplicate records between the two applications. For example, if you have entered Daniel Brunner as a contact in Microsoft Dynamics CRM and also as a customer in Microsoft Dynamics AX, you have duplicate records for Daniel Brunner.
Microsoft Dynamics CRM allows users to enter duplicate records, with duplicate keys, for Microsoft Dynamics CRM accounts and contacts. This can cause problems when the integration service tries to integrate the records.
If duplicated records are not identified before you integrate Microsoft Dynamics CRM contacts or accounts with your Microsoft Dynamics ERP customers, you will end with four records for the same person between the two applications.
Set up duplicate detection jobs and rules in Microsoft Dynamics CRM for the account and customer entities to prevent these duplicate record issues.
It’s suggested that you use one of the options listed below that are available in Microsoft Dynamics CRM to keep duplicates from entering the system in the first place. See your Microsoft Dynamics CRM documentation for additional details.
- Set up Microsoft Dynamics CRM duplicate detection rules In Microsoft Dynamics CRM, set up or modify duplicate detection rules for the entities to integrate. Click Settings > Data Management > Duplicate Detection Rules. The default duplicate detection rules are listed. Use the duplicate detection rules for accounts or contacts using attributes and criteria that make sense for your business rules. Duplicate detection rules in Microsoft Dynamics CRM are based on contact e-mail addresses by default, and the Connector for Microsoft Dynamics maps e-mail addresses based on accounts or customers.
- Set up Microsoft Dynamics CRM duplicate detection jobs In Microsoft Dynamics CRM, set up duplicate detection jobs for the entities to integrate. Click Settings > Data Management > Duplicate Detection Jobs. Add a job to catch duplicates and notify someone in your organization for each entity to integrate.
Comments
- Anonymous
September 14, 2011
Hi Char, could you just clarify: I do initial integration for client who has 12000 Customers in NAV and 20000 Accounts in CRM. I know for sure that 12000 Accounts are duplicates for the NAV Customers, and each Account in CRM has NAV Customer No., so defining duplicates is not an issue. My question is, if I follow instructions above:
- Create Duplication Rules
- Create Duplication Detection Job
- Run Initial sync What I will have after sync will complete? A: Is Connector just update duplicate Accounts with Integration Key? B: or in CRM appear 12000 additional accounts which recognized as duplicates? If (B:), is there any fast way to merge them? Because if merge them one by one, even if spend only 30 seconds per pair, it takes 100 hours ... Thanks, Konstantin
Anonymous
September 14, 2011
@NavDeveloper, Connector fully supports CRM duplicate detection rules and messages. This means that in the scenario that you outline below, when a duplicate record is detected on your initial sync into CRM, CRM will throw a "duplicate detected" exception when the Connector attempts to create a new account. The CRM adapter will catch this exception, and then send the record back into CRM as an update - rather than a create. So the answer to your question is A. After the initial sync, using duplicate detection, you will still have 20000 accounts in CRM and the 12000 accounts that are also in NAV will have been updated to have the same information stored on them that they have in NAV as well as have an integration key assiged to them.Anonymous
September 14, 2011
Awsome!! Now it's completely clear. Thanks!Anonymous
September 25, 2011
Hi I am one the persons who asked this question :) But another issue has arised. We have installed the Connector for Microsoft Dynamics and are integrating AX to CRM 2011. The issue we have is that we need to do a resync of all the accounts from AX to CRM to get rid of duplicates with the CRM duplicate detection enabled. We have tried to delete one of the duplicate accounts created by the connector in CRM and have reset the DAXINTEGRATIONID on the account in AX. By this it will "merge" into the existing account in CRM 2011 but it doesn't update the address info. We can also see that it doesn't update the DAXINTEGRATIONID column in AX which we think is why it can't find the right addresses to update. What do we have to do to be able to resync the accounts from AX to CRM ?Anonymous
September 25, 2011
@Jack DS - I would strongly recomend that you contact support with this issue as they have worked though it several times for other customers and might have scripts that you can use already. That being said, The DaxIntegrationId from AX is mapped to the KeyId field in CRM, meaning that anywhere in the CRM database that account is refered to (such as on addresses or any lookup to accounts) that GUID will need to be updated to reflect the new value in AX.Anonymous
September 26, 2011
I have created a support case with the AX team and hope they can help me out. The daxintegrationid on the AX account should be updated with the guid of the merged/updated account in CRM at first. That doesn't seem to happen and that's why I think the address updates doesn't work. If anyone else have a clue on this one let me know. If I get a solution from MS support i'll post the answer here if anyone else sometime should need to do a reinitialization.Anonymous
September 26, 2011
Actually, I think that the unique id of the CRM account should be updated with the DaxIntegrationId from AX first. But we'll see what support can do :)Anonymous
September 26, 2011
Actually, I think that the unique id of the CRM account should be updated with the DaxIntegrationId from AX first. But we'll see what support can do :)Anonymous
September 28, 2011
The comment has been removed