Connections don’t merge, so be careful with duplicate records

Update 22.3.2012: this has now been fixed in Update Rollup 7 for Microsoft Dynamics CRM 2011 (KB 2600643). Go and get the file here, unless you’re using CRM Online.

Connections are a nice new feature in Dynamics CRM 2011 that allow you to create ad-hoc relationships between two records of almost any entity type. Additionally, you can specify roles for both the Connected To and Connected From parties, to describe the connection in more detail, as well as provide start and end dates for the connection. These are very handy for recording non-hierarchical relationships between contacts and accounts that tend to exist in the real world. As an example, a person working as the CEO of Company A might be a member of the board in Company B, which means they should be visible under both accounts. Company A would then be the parent account of the contact, whereas there would be a connection between the contact and Company B.

Another common real life phenomena is that duplicate records find their way into the CRM database. This can be due to data imports from external databases, web forms feeding in new contacts, or simply two users being unaware of each other’s records and entering data with slightly different spelling or email address variations. Luckily Dynamics CRM has a built-in functionality that allows you to merge duplicates from the database. This process will move all the child records from the subordinate record to the master record, thus ensuring that everything remains linked to the active record and not the deactivated duplicate.

Except that for connections this doesn’t happen! Once the merge is done, all the connections will still be referencing the inactive record, not the master record. In the aforementioned example, you would have effectively lost the information about the contact’s relationship with Company B. Even though you could still see it by opening up Company B’s record and seeing the connection there, how would you ever have known where to look?

There is an existing feedback item 683301 on Microsoft Connect regarding this functionality:

Here’s a quote of the comment I’ve posted on the item:

I think this is a serious flaw that undermines the perceived reliability of the Merge Duplicates feature in the eyes of the end users. The merge screen indicates that all child records related to the subordinate record to be deactivated would be transferred to the master record, but it doesn’t warn that connections would need to be manually checked.

The merge process works just fine for custom entities, activities and pretty much everything except connections. Why would the user ever want to leave behind some non-duplicate information to the deactivated record? By merging two accounts or contacts the user is effectively declaring that these represent the same object in the real world. If something in the database has a relationship with either of these records, it should be carried over to the active record, as the inactive record no longer serves any other purpose than indicating the prior existence of a duplicate entry and the possible differences in attribute values compared to the current active record.

If you think connections should be transferred over to the master record when merging duplicates, be sure to log in to Microsoft Connect with your Windows Live ID and cast your vote on this item. In the meantime, if you’re planning to use the connections entity for recording any data related to accounts, contacts, or leads, my suggested options are:

• Don’t do it. Create a new custom entity for recording this data, as they will merge over to the master record just fine.
• Develop you own plugin for capturing any merge events and updating the related connection records accordingly.