There is an on-going problem with most modern CRM systems which is the Account – Contact problem. In short, most CRMs assume a Contact belongs to just one Account and an Account has many Contacts. Often this assumption is not valid. Common examples include medical practitioners, who work for a hospital, have their own practice and are part of a research group, and higher education where an academic may be part of a research group, and have a position at one or more universities.
In the case of Dynamics, this assumption was baked into the product right at the start. I remember attending the Microsoft CRM 1.0 beta training sessions where it was clear design aspects had been ‘inspired’ by SalesLogix, a ‘sunsetted’ product owned by Sage. SalesLogix had the one to many Account-Contact structure and Microsoft continued it in Dynamics. With the new CDS framework being built on Dynamics, this assumption is here to stay.
So what do you do when you need to link Accounts and Contacts? By my reckoning, there are four different ways to link them in Dynamics:
- The out of the box Account-Contact relationship
- An N:N relationship
- A manual N:N relationship
If possible, use the out of the box. It comes with some nice features built in, such as roll-up which saves having to think too hard when it comes to configuration, and other features, such as the old Word templates, play nicely with it.
The novice architect may be tempted to leap directly to a configured N:N relationship as an option if a Contact needs to be linked to multiple Accounts. There is nothing wrong with this but a configured N:N hides the necessary linking entity. Therefore you cannot specify anything about the nature of the relationship. If there is the possibility in the future that you will need to specify the ‘role’ the Contact plays with the Account, the N:N is a sure path to Spießrutenlaufen.
Connections is a good next option. The odds are you will already be using Connections for other ad hoc linking so it will dovetail into this use without the need for exception training. Setting up a Connection is a few more clicks than the out of the box Account – Contact relationship but offers a lot more flexibility.
Finally, there is the “developer’s choice”; the manual N:N where you create a linking entity with a lookup to an Account and a Contact. This provides the most flexibility at the sacrifice of usability but that can be coded around, thus the developer’s choice.
In my experience, Connections are a reasonable proxy for a many to many relationship between Accounts and Contacts but, like many things in Dynamics, there is always more than one way to excoriate the feline.