Question

Enabling SFDC contact object at the relationship level

  • 28 October 2016
  • 13 replies
  • 103 views

Our org has a SFDC contact object. Is it possible to leverage this object on the relationship level, assuming we add in the right fields to identify the product offer? If it is only at the account level, is there a roadmap to make this functionality be available on the relationship level.

13 replies

Userlevel 7
Badge +2
@Jeff Coleman - how did you and I both miss this?  A sign I need to slow down and RTFM.

Thanks Sidhu!  Agreed on the mic drop.
Userlevel 7

Userlevel 7
Badge
Seriously... I have nothing to type. My mind is blown.

Please reply with a.gif of you dropping the mic. You deserve it.
Userlevel 6
Hi Jeff, 

You can control which contacts to show by configuring the Relationship Contacts section added to R360. I agree that this config should be defaulted to show contacts from the same account the relationship belong to. 

To configure, edit the relationship contacts section and then click on the configure icon against the Contact field



Then use the filter configuration to choose Account ID from Contact to be equal to the Relationship Account. 



Another thing you would notice here is that you could also use this configuration to add additional fields like email to the contact search criteria. 
Userlevel 7
Badge +2
Thank you Jeff C for pointing this out (as I am also just starting to figure out how to implement relationships in our environment and had not yet come across this).

One of the big problems I see with this is that I can assign a contact from an unrelated customer to this relationship.  And there is no way to tell when I'm adding the contact from which Account from it's coming.

In the example below, this is a relationship created on a North American big-box retailer account.  I am able to add contacts from a Latin American government agency.  The two are completely unrelated. 



In my sandbox, I only have a handful of accounts, but what if I had two competing big-box retailers each with a contact named Steve Davis?  It appears that I would be able to inadvertently assign the Steve Davis from Big Box Retailer A to the relationship under the Big Box Retailer B.

Karl - your use case is probably a valid one for some companies, but as you stated, the typical use case would be assigning contacts from the same account.  I think the above is a much bigger risk than the benefit to having wide-open relationship contact mapping. Shouldn't the default functionality be driven by the typical use case vs. the edge case?

I believe the default functionality should be to restrict the adding of contacts to a relationship that exist at the account level AND/OR contacts that exist on another account under the [i]same Customer (Account Hierarchy).  Then there could be an administrative override to permit you the ability to add contacts from any account to a relationship if you so choose.  Perhaps that should be at the Relationship Type level?

This is a BIG blocker to our ability to use Relationships.  I'll reach out to our CSM to let him know.
Userlevel 6
I think this is clear but just to add one more point so we are all on the same page: it is really important to remember that a given contact can be associated with any number of Relationships.  Relationships to Contacts is many-to-many.
One of the big wins here is that you should never need to duplicate Contacts to work with Relationships.  If you have previously tried to model things by adding lots of subaccounts, you will realize how often this requires you to duplocate contacts and how painful that becomes. 
Userlevel 6
Jeff: you are totally right that the typical use case would involve associating contacts to the Relationship that are on the aligned Account.  However, there are some use cases for associating contacts from other accounts so we made that possible.  To throw out one example: suppose that your solution is used to drive marketing campaigns for brands, sometimes direct and sometimes via an agency.  One way to model things is to have Accounts for both Agencies and Brands and a Relationship Type that captures the Campaign.  In this case, a Campaign on an Agency Account might very well want to capture key contacts from the Brand Account.  By the way, another cool thing in this scenario is to realize how straightforward it is to show on the Brand Account all Campaigns for that Brand, even if some of them are being handled via an Agency.    
Hi Jeff, Not with Gainsight but our org created additional relationship level flags that can be managed at the C360 level. The R360 would just show contacts related to the specific relationship. This did require us to discourage adding/managing contacts on the R360 and to only do that on the C360 though to avoid creating duplicate contact records.
Userlevel 7
Badge
That was the part I missed. Adding the related list to the R360!

New question... I would have expected that search field to filter (by default) to only the contacts associated with the Account. In my test relationship the account has only 1 contact, but my list comes back with many more.

I think my hope would be more of a "contact picker/manager" of sorts whereby the CSM could go here and browse the existing contacts, selecting some to associate to the relationship, or directly adding contacts if they're not already captured. I could well be missing this (again!) as I'm just starting to dig into relationships in practice!
Userlevel 7
Also, in case there is confusion around 'manually' adding Relationship Contacts, it's possible to do so directly from that section on the R360.

      



Just need to make sure that 'Contact Id' (lookup field) is added to the layout, to be then used to find and associate the right Contact.

      

Userlevel 7
Hey Jeff,

Just so I fully understand your comments: 'Relationships Contacts' is built to let you associate certain key Contacts to the Relationship, out of the hundreds that you have available at the Account level. Because, as you said, only a few matter for a particular Relationship. 

So when we use 'Relationship Contacts', we are leveraging SFDC Account Contacts and letting you pick the right ones + add additional context (Relationship role, etc.). Is the gap then around not being able to add/manage folks outside of the Account Contacts structure? Or is there a concern around having to explicitly associate these Contacts?
Userlevel 7
Badge
Denise -- I think the broader question may be around how the relationship CSM should be managing the associated contacts. I think it's odd/frustrating that there's no way to leverage the SFDC account contacts from the relationship level and to manually add those to the relationship.

For a specific example, we have accounts with hundreds and hundreds of contacts associated. There are a small few that the CSM focused on integrations cares about with respect to that relationship. What's the best practice for identifying the 2 or 3 people that are key to that relationship, adding those to the Relationship Contacts object, and then maintaining them over time. (Because even if the sales team fully identified the client team on the opp, we know somebody is going to leave and be replaced soon enough!)
Userlevel 7
Badge
Gainsight has, as part of our Relationship feature, the Relationship Contacts object.  This references the SFDC Contact IDs specific to that relationship.  You would want/need something in the contact record that allows you to figure out which relationship to tie them to in order to automate it.

Here is tutorial for loading to that object that associates a SFDC contact to a specific relationship:

https://support.gainsight.com/hc/en-us/articles/228077488-Tutorial-Load-to-Relationship-Related-Obje...

Reply