Capturing Multiple Contact Roles In CRM

A design challenge I often come up against in CRM implementations is the need to capture a Contact against multiple Accounts. For example, a doctor may work at multiple hospitals.

Out of the box, Dynamics CRM (and most CRM systems for that matter) assume a Contact works for only one Account, which is often the case, but they do not make it easy to relax that assumption. Here are three ways, I have used in the past, to get around the problem.

Connections

The simplest way to handle the problem is with Connections. Connections allow you to associate practically any record in CRM to any other record.

The advantages of this approach are:

• Easy to maintain
• Easy to set up

However, there are significant disadvantages:

• While you can add an email field to the form, the entity cannot be made into an emailable entity, limiting what you can do with it
• You cannot add Connections to Marketing Lists, forcing you to use the one Contact record and its primary email address
• You cannot associate Activities to the Connection, meaning they sit with the Contact
• There is no rollup of Activities through Connections to the associated Account
• The Connections do not sync to Outlook, only the Contact record

A Contact Role Entity

Another option is to create our own custom version of the Connection calling it, say, Contact Role. This will be a child entity to both the Contact and Account. The advantage here is we can make it an emailable entity and associate Activities to it.

The advantages of this approach are:

• Still quite simple to manage
• We can email with this entity and use templates
• We can associate Activities to the Contact Role

Disadvantages are:

• We still cannot add Contact Roles to a Marketing List
• Activities do not roll up from the Contact Role to either the Contact or Account records
• The roles do not sync to Outlook, like the first option

A Person Entity

Finally, we can create a parent entity to the Contact which represents the person, with the Contact now representing a job that Person does at an Account.

This approach makes me nervous because it fundamentally changes the meaning of the Contact record and, therefore, any functionality Microsoft has built in around Contacts may be compromised.

However, it does solve a number of problems for us.

Advantages of this approach are:

• The Contacts can be added to a Marketing List (although the Person record cannot)
• We can email using the Contact records as we normally do
• We can add Activities to the Contact record, as usual
• Contact Activities roll up to the Account, as usual
• The Contacts do sync to Outlook

Disadvantages are:

• It is quite complex and takes a bit of training and use to become comfortable with it
• Some automation is required e.g. a workflow that automatically creates the Person record when a new Contact is created
• Allows for duplicate Contacts for the same Person so Duplicate Definitions need to be managed with care
• Information which ideally belongs on the Person record e.g. Gender, Birthday and Salutation sits on the Contact record and must be dealt with in some manner
• Activities and Connections do not roll up to the Person record (although code can get around this)

Conclusions

For CRM systems used for stakeholder management, there is often the requirement to associate a Contact to multiple Accounts. CRM struggles to handle this out of the box, but there are ways we can extend CRM to get close to meeting the requirement. While none of these possible solutions are ideal, depending on the specific requirements of the client, one model will likely win out over the others and deliver a system which meets their needs.

***Post Script*** Thanks to Jerry Weinstock, fellow CRM MVP, for reminding me about the issues with Outlook sync in the approaches