Multiple Persona or Profiles per customer contact in Microsoft Dynamics CRM Online & CRM 2016 on-premise: CRM contact architecture approach

A CRM contact with multiple personas or separate individual profiles is a fairly common scenario in many Dynamics CRM projects. For example:  A contact could be a Managing Director of an organisation while at the same time they are non-executive director in a different firm or sits on the board of a Charity.

In Dynamics CRM, a contact is normally one person. Setting an individual contact to have multiple profiles and personas can be delivered in a number of ways – arguably most of them are not 100% ideal.

First option for delivering the multiple personas for the same individual contact is to create a custom entity for each persona/profile and have the contact record as a parent (or a child) for each one of these entities. Other options, which I wouldn’t recommend, is to create a custom entity for each persona and not include or use the contact entity at all – i.e. you will be re-creating the contact entity multiple times, once for each persona. This is not a good practice and a highly discouraged approach.

Another option which is also not recommended, but more common, is to create a separate contact for each persona allowing for duplicate contacts – for example: John Smith, the Director of company X and another contact, John Smith, sitting on the board of company Y. Again, duplicating contacts is never a good practice.

There are other additional options to achieve the multiple persona scenario in Dynamics CRM such as as customising the contact entity heavily so that it allows for capturing multiple personas on the same form and entity. Again, this might work for some CRM solutions but is not ideal.

Let’s explore the first option further. In this approach, a custom entity for each persona or profile is created while having the contact entity as either a parent or a child for each custom entity. This option is the most commonly used and was unofficially suggested by a highly qualified Microsoft contact for a number of scenarios. One main challenge, among other challenges and limitations of this approach, was to be able to display all contact information within the custom entity for each persona.

For example, let’s say John Smith is an Ex-employee, a Director in company X and also a non-executive director on the board of company Y. You will have 3 persona records (same custom entity or different) all linked to the same contact record. Then, if there is a process where you want to show 1st Persona, you will use data from the 1st Persona form and so on, just using the relevant persona entity record.

However, if you want to show contact information from the contact record such as mobile number or email address, you were left with limited options as you couldn’t directly show this information within the persona entity form. Your options where to copy the contact information across from the contact to the persona record and always keep them both in Sync programmatically. Synchronising the contact information was a lot of overhead of custom development though. The other option was to show the persona without the contact information and then expect users to click their way through from the persona record all the way up to the parent contact record, just to be able to see the persona phone number! This wasn’t helpful either.

Now, in Dynamics CRM 2016 and Dynamics CRM Online, there is a new feature that I found to be very useful to help resolve this limitation in the persona situation or even in other situation where you need to show fields, information or data from the parent record on the child entity form.

My suggestion is to do this using calculated fields. I found this to be very powerful. You can now go to the form of any entity and add a calculated field that shows the data from the parent record. So in our persona example, you could simply have the contact entity as the parent of the persona custom entity and then add a calculated field on the persona entity form. This calculated field is then set to be equal to the relevant parent contact record information such as: mobile number or email address. This is done just like you would do a formula on CRM calculated fields where you are now able to select the parent field from field calculation formula building screen.

 

This applies to many other situations where you can show data or calculation of data from parent records of any child entity form. I found it to be a powerful new feature with many  other useful uses. Anyone else found this interesting or have other recommended approaches?