of the
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
- Connections
- 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.
I agree that this is a tricky area but I would just like to add that connections would be great choice if only they were a bit more configurable. A present I find they mostly confuse users if used directly. There are exceptions with the specially created subgrids in Opportunity and Lead for Stakeholder and Sales team which are a usability front for connections. The problem with connections, is that there is no way (that I know of anyway) to limit to which entities connections are allowed to. Let’s say you are on MD House and want to connect it to the account “John Hopkins Hospital”, In The lookup you will first have to select which entity to connect to, and for a user of limited skills of data abstraction this might become weird. “Connect MD House to an Invoice? Order? Goal? Which was it? What does this mean?
So from that perspective I would recommend the manual N:N approach which with quick create does not become too clunky, and with custom control framework and editable grids and perhaps Canvas Driven Apps can be really beautiful.
My 0.02 Surströmming.
You can limit which entities are used for a given Connection Role. It is part of the configuration. There is also my Better Way to Use Connections suggestion which can help.
With the new features of the custom control framework, it may be possible to overcome the major drawback of ‘too many clicks’ with the manual N:N which would make it compelling.
Are you aware of a marketing solution (eg. ClickDimensions) that can work with any of the options in this post, particularly being able to get information from multiple associated accounts for use in ‘personalized communications’?
None of the marketing solutions I’ve found appear to offer the ability to let e-mailings be sent to duplicate e-mail addresses, but we must be able to e-mail a contact about all accounts he/she is registered for. Asking these contacts to create unique addresses for each of their accounts in our system is a no-go.
Without getting into details: right now pay a not-so-insignificant monthly fee for ClickDimensions *and* have to use a different third-party e-mail provider to e-mail our contacts about each account they’re related to.