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?

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

  1. Using calculated fields for replicating the field values from parent to child record sure is an interesting use case for this feature. Did you do any comparison on the pros and cons of this calculated field approach versus the use of a Quick View Form to display the parent record fields on the child form?

    The dilemma of one person working in different roles for multiple organizations is something that’s unfortunately quite complex to handle in a relationship management system like CRM that technically should be able to adapt to it. In customer projects I find that the presentation and management of the personas’ profile attributes is not the trickiest part, but rather the expectations that users have on how CRM should be able to view the activities regarding this one person from over a number of different roles. As we know, the activity rollup feature in Dynamics CRM is not something you can easily customize, so usually a lot of compromises and user guidance is needed for working with the activity data.

    Quite often there are scenarios where the single person working in two different organizations will also have different email addresses in each organization, so having a single master contact with N persona/profile child records isn’t always ideal. Sure, you could add a couple of additional email addresses for the contact to support the tracking of incoming emails, but then when the customer wants to send outbound emails via campaigns or workflow, this will become a problem.

    XRM is a great platform for managing hierarchical relationships between records, but these non-hierarchical networks of relationships across different entities are something that isn’t really a good fit for the system’s feature set. It’s a shame that the Connections feature from CRM 2011 has pretty much been left to rot in terms of UX, as it would have had great potential for addressing the network vs. hierarchy question when developed further. Community solutions like Network View from Scott Durow ( make me think that THIS is what CRM really should be about, rather than a strictly hierarchical system.

    1. Some interesting thoughts for sure Jukka. The use of calculated field to bring data from parent entity helps in creating a quick view form (card form) for the custom persona entity with the parent contact information such as mobile number and email. As you can’t embed a quick view form of the parent contact entity into the quick view form of the persona custom entity, calculated fields became a good solution. In regards to multiple emails, that’s where the advantage of each custom persona entity comes. If there is a requirement, you can have specific email for a specific persona entity, etc. There is another interesting discussion on the same subject on my LinkedIn post. I’ll try to move the discussion to the post itself for future reference for readers benefit.

  2. Mohamed – hello and thank you for your post. I have done much thinking on this topic and find the implementation of personas challenging. However one decides to implement the contact-persona concept is secondary to how it is then utilized. A precise implementation would allow visualization of the entire customer journey in terms of personas not only persons. As an example, for a given individual you would be able to see their entire engagement graph – lead to contract or order – in context of the persona(s) under which they were performing. It would be necessary and non-trivial to associate sales activities with not only the contact, but also the performing persona for the contact. In embellishing what Jukka mentioned, I find Dynamics CRM architecturally rigid in the wrong places, discouraging things like asymmetrical relationships. Thank you again.

    1. Thanks Doug. Definitely a valid point and I agree the implementation will always be subject to what the business needs are. Some business may want the persona to be at the centre of the journey and its reporting while other requirements may be more focused on the wholistic 360 degrees of the contact. Thanks for your input.

Please comment or leave feedback