Salesforce’s Summer ‘16 release brought us the awesome ability to link a single Contact to Multiple Accounts, a feature that has been in the Top 5 of the most popular ideas on the Salesforce Community for years. After thousands of enthusiastic votes from admins everywhere, the feature became generally available after a short beta. The Summer ‘16 release notes provide great background on the feature, how to enable it and some recommendations on how activities should roll up once enabled.

After reading the release notes and following the instructions, we here at Silverline still had a few questions about how the Security and Accessibility aspects of the new feature work, as well as what exactly happens when you turn it on. So, we rolled up our sleeves, got to testing, and wanted to share what we’ve learned with the community! We hope this information helps you in your evaluation – and be sure to send us a comment if you have questions or have learned something else!

Enabling Related Contacts

When you first enable Related Contacts, Salesforce will create “Direct” Related Contacts for all Contacts that are linked to their Primary Account. That’s good news – there is no need to perform a data load to the Related Contacts object. What it also means is that you could actually remove the standard Contacts related list from the Account page as you can create a direct contact from the related list, merge contacts, etc. Removing the standard Contacts related list will not make you lose any functionality, given that the Related Contact is more or less serving as both the Contact & the Contact Role in a single object.

The Activity Roll-Up

Salesforce recommends that you disable Activities rolling up to the Contact’s Primary Account – which means that when you relate an Activity to a Contact (via the WhoID field) but not directly to an Account (via the WhatID field), the Activity will no longer appear in the Activity related list for the primary Account.

Enabling the Contacts to Multiple Accounts feature will reveal the new setting (under Activity Settings) labeled “Roll Up activities to a contact’s primary account”. This new setting will be defaulted to True, which means that any Activities which are associated to the Contact (in the WhoID) without a Related To (in the WhatID) will be displayed in the Activity related list of the Contact’s Primary Account. Disabling this feature will not remove any Activities displayed at the Contact’s Primary Account prior to the feature being disabled. This will only affect Activities logged after the feature is disabled.

Activities logged where a Related To is present (i.e. an Opportunity or a Case) will display the Activity at the Contact, the Account of the Related Object (i.e. Opportunity or Case’s Account) and the Opportunity or Case against which the Activity is logged.

What about Sharing?

After you enable Shared Contacts you may notice that you do not have any Sharing settings for the Related Contacts object. You may be asking yourself the same questions we had, such as:

• Who can see the Related Contact?
  • The Contact Owner?
  • The Account Owner?
  • The Account Team Members of the Primary Account the Contact is linked to?
  • The Account Owner of the Related Accounts?
  • The Account Team Members of the Related Accounts?
• Who can edit the Related Contact?
• Does seeing a Related Contact imply any permissions about seeing other accounts they may be linked to as Related Contacts?

Our Findings

We learned that enabling the feature does NOT add the Related Contact object to the Account Sharing Rules, similar to the way Opportunities and Cases can be granted access via the Account sharing rules.

After some investigation, we found out that the Related Contact IS, however, controlled by access to the Contact record itself, meaning that if you do not have access to the Contact, you will not have access to the Related Contact record either, even if you own or have access to the Related Account. If you have access to a related record on an Account such as a Contact or Opportunity, you have access to the Account itself – however, it is the Contact in this situation that ultimately wins out.

If the Org-Wide Setting for the Contact object is set to “Controlled by Parent” (i.e. the Account), the Account access will drive the Related Contact’s sharing, which means that if you do not have access to the Account, you will not have access to the Contacts nor the Related Contacts unless the Contact is manually shared.

If the Org-Wide Setting for the Contact object is Private (i.e. NOT controlled by the Account), then the Contact access is ultimately driving the Related Contact access. This means that if you have access to the Related Account but not the Contact, you cannot see the Related Contact record when viewing the Account.

Similarly, if you can access the Contact but NOT the Related Account, when you view the Related Accounts list from the Contact page, it will allow you to see the Relationship record, but if you click on the name of the Related Account to access its detail page, you will receive an insufficient privileges warning. That said, the name of that Related Account is still visible from the Contact page.

What about Reporting?

Another hot topic of conversation that arose in our testing was – what about Reporting? Let’s not forget that enabling Shared Contacts may introduce an entirely new structure to how you run your reports on Accounts & Contacts. Certainly, we want to avoid confusing users with report types like Contacts & Accounts or Contacts with Shared Accounts.

Enabling the new feature does NOT create new standard report types by default. Ultimately, we would recommend that admins enabling this feature be sure to create new Custom Report Types using either the Contact or Account as the Primary Object and the Relationship as the secondary object, in order to meet the use cases needed for your specific reporting requirements.

What to Expect in Winter ‘17

The Winter ‘17 release pushes the bar even further with Shared Contacts, which will allow you to now:

• Relate Person Accounts to Business Accounts
• Write Triggers on the Account-Contact Relationship Object
• Write Validation Rules on the Account-Contact Relationship Object
• Access via Community Builder templates
• Edit or Delete Relationships even more easily

What about Contact Roles?

Ultimately it looks like Shared Contacts could be the next generation replacement to our once beloved Contact Roles object. The flexibility of the Shared Contact feature leaves the Contact Role object in the dust and overcomes many of the limitations like no custom fields or triggers that we’ve had to work around in the past.

So I want to test out or implement this cool new feature. What do I do next?

We recommend that you (as always) enable in a sandbox first and start a checklist that considers the following:

• What is my organization accomplishing by enabling this feature?
• What is the business value and how can I effectively communicate that to users?
• What are some good examples of how this new feature will look once enabled so I can show users what to expect?
• How does enabling this feature impact my Org-Wide Settings?
• How does it impact my sharing rules, permission sets or profile settings?
• Do I have Person Accounts enabled? If so, should I enable this new feature now or wait until Winter ‘17 to simplify the change management?
• Do I need to perform data migration / updates to accommodate for the activity roll-ups?
• Do I already have a custom joiner object or standard Contact Roles being used? If so, do I need to perform a data migration to move these relationships to the new Related Contacts/Related Accounts object? What functionality in my org may be impacted by removing these objects?
• What reports will be impacted? Do they need to be rewritten and/or substituted with custom report types?
• What dashboards will be impacted?

We hope this checklist can get you started. If you have questions, be sure to send us a comment or a tweet! And if you’ve learned something else through your own testing efforts, please let us know!