Related sites:

Newsletter: Perspectives on Power Platform

Company: Niiranen Advisory Oy

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.
While we’re on the topic, I also tested what happens to the old Relationship records that were used for connecting account, contact and opportunity records in versions prior to CRM 2011 (and are still visible in an upgraded organization). The result? When merging two contacts, any relationships referencing the subordinate record are deleted! Yeah, crazy, I know. If you’ve got any insight on what is the reason behind this perplexing system behavior for either connections or relationships when dealing with duplicate records merging, please leave a comment in the box below.

7 Comments

  1. hi, i agree with your post, but was not able to cast my vote as the link seemed broken (“page not found”).

    any update to this issue?
    will there be an official KB or response from MS to document they have acknowledged this issue?

    thanks!
    -Will

    • Excellent work, James! I downloaded your solution, installed it on a test environment and the merging of contacts moved the connection from the deactivated record to the active one, just like you’d expect it to work out of the box. Thanks for releasing the solution, it’ll surely help organizations in making sure customer information is not lost in the process of merging duplicate records.

  2. Also, the ‘Follow’ ed records don’t get re-associated on merge.

    For example: If I follow contact A. and this contacts A gets merged into contact B.
    Ideally my ‘follow’ record should get re-associated to contact B but it still keep pointing to contact A which is now in the deactivated state after merge.

    Any solution for this?

    • That’s a great observation! Considering the Activity Feeds was an optional solution released after CRM 2011 RTM, it’s sort of understandable that the merge functionality in the core platform wasn’t updated to handle this special entity and its use cases. Looks like the behavior remains the same in CRM 2013, though, even if the feeds are now built into the product. Neither follows nor the actual posts related to the record are carried over to the new master record from the deactivated record during a merge operation.

      I recommend adding a suggestion on MS Connect about extending the merge functionality also cover the Activity Feed related data. This may be a tricky thing to implement, though, as all the Activity Feed related functionality has in practice been replaced with Yammer in the development roadmap for Dynamics CRM (with MS publicly stating that no new features would be introduced there), so also any content stored on Yammer should reflect the merged records’ information accordingly.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.