About half way through CRM 3.0 I took over the sales force automation functionality; some of the first questions from partners on the beta programs were around Relationship Roles: what are they, how do they work, what are they good for and what the deal is with all the dots:
It took me a few weeks but I finally figured it out so now from me to you here is a discussion on Relationship Roles.
Most everyone who has some CRM background or knowledge understands that one of the things that you want to track in CRM are the relationships between people and things in the system. Sometimes these relationships are very well defined and don’t differ much from one object instance to another: think of an Account Owner or a Primary Contact. But sometimes they are more free form and may exist in multiple quantities: like a “Technical Decision Maker” or “Business Decision Maker” on an Opportunity or an Account. CRM 3.0 introduced the notion of Relationship Roles to provide a solution for those more free form relationship types. For greater flexibility for those well defined relationship types talk to the Phil, he’s working on something.
There are two sides to using Relationship Roles in MS CRM: defining the relationship role and then applying the relationship role. And you don’t need to do the first. Let me give a simple example: Let’s say that you sell bikes to Weekend Tours and that your customer, John Donovan, is the person that has the final purchase decision. It’s interesting to know that John Donovan works for Weekend Tours and you can capture that relationship pretty quickly and easily without defining a role, just navigate to the Account’s Relationships tab and add a relationship:
You can add some text into the Description box if you like.
This is sort of interesting but in fact there are other (and better) ways to determine that John Donovan works for Weekend Tours (like making Weekend Tours the Parent Customer for John Donovan). But Weekend Tours may have a lot of employees, how do you capture and communicate that John Donovan is the person to work with at Weekend? You define a relationship role. In this case, we’ll call it Business Decision Maker. The “BDM” can be a decision maker for the Account as a whole or for a specific Opportunity. We can capture this in the definition of the role using those dots:
The BDM is always going to be a person so this is a Contact Role that can apply to an Account or an Opportunity. The person making the business decision at Weekend Tours may be different than the people doing the technical evaluation. Those Technical Decision Makers (TDMs) are critically important in making the sale (and often get overlooked by inexperienced sales people). We’ll define another role called Technical Decision Maker too, it will be just like the Business Decision Maker role in terms of who and what it applies to. Now that these are defined we can create a much more interesting view of Weekend Tours:
Here we have John defined as the BDM and we’ve also identified two TDMs as well. For a specific Opportunity with Weekend Tours you might also define the BDM and TDM roles. (Opportunity relationships look a bit different in the UI but you won’t have trouble making sense of it).
A couple of asides here: Note that the “Role 1” column above doesn’t have anything in it – it doesn’t need to. If you’d wanted to define a role for the Account in the relationship you could have done so but it isn’t necessary. In fact I’m usually hard pressed to find good cases where there are reciprocal relationships; some possible ones between Contacts would be “Father” and “Son”, “Doctor” and “Patient”. Each of those would be defined as separate Contact to Contact roles. The other thing that I have to confess is that those dots only provide a way to filter the user interface. Referring to the second image in this post, the object types in “Party 1” and “Party 2” determine which role names show up in the “Role 1” and “Role 2” select boxes. This is a nice way to enforce some consistency in role assignment (e.g. making sure that no one assigns a “BDM” role to an Account), but in retrospect the feature would be much more usable if you didn’t have to do so much work to define the relationship role.
Now, this is where it gets really cool (and frankly a little more difficult to figure out). Say you want to run a direct marketing campaign and you want to send different materials to BDMs and TDMs (nice photos of your bikes to the former and technical spec docs to the latter). Just create an advanced find query that looks like this:
Here, you’re returning Contacts where their related entity “Customer Relationship (Party 2)” has a “Role 2” that is equal to Technical Decision Maker. The query ends up being a little hard to understand because the Relationship Roles are implemented as a join entity and not as a property of the entity that you’re trying to return. I don’t expect that too many end users would figure this out on their own. I’d suggest creating a few of these as saved views and then sharing them out to show your team how much great data they can get out of CRM.