In Part I of this post, we explored the benefits of a Salesforce Customer Community, as well as some of the challenges one may encounter in actual implementation. Specifically, we identified the challenge of account access facing external, customer users. If your organization utilizes the standard Salesforce Account Model with a hierarchy of accounts, your customer contacts may be listed on service cases for multiple accounts if they act as contacts to cases for more than one bill-to or ship-to site. This will become a larger issue once your customers begin creating their own support cases from your Customer Community. We saw last time that our customer, John Doe – who is a contact Acme Corporation in Waterbury, CT – is only able to create cases for his default account:
In our last post, we discussed four possible solutions to this problem, including creating duplicate contact records, Salesforce’s new related contacts functionality, sharing sets, and sharing rules managed by Apex. In this post, we will dive into the pros and cons of each, along with the scenarios (if any) in which each solution may make the most sense.
- 1. Duplicate Contacts/External Users
While the relationship between contacts and accounts is one-to-one, there are no restrictions against creating duplicate contact records for a single individual. Creating contact records under each account to which a user needs access, and then enabling each contact as an external user, would allow your customers to access each of their accounts for the purpose of creating new support cases via separate logins.
It’s worth noting that this solution will afford your customers the necessary access where needed. Your organizations administrator will simply need to create new contacts and external users for each customer/account combination needed. However, there are several significant drawbacks to this approach:
- Salesforce usernames, which must take the form of an email address (real or fake), must be unique across all instances. This means that each of your customer’s logins must leverage a unique email address. Recall that, in our example, John Doe needs to open support cases on behalf of six different accounts. Therefore, as evident in the image above, John Doe will need to login to your Customer Community with one of six different usernames.
- Salesforce Customer Community licenses are not free. In our example, John Doe’s expense to access your Customer Community has been multiplied six-fold. John Doe is also not our only Customer Community user. This approach will increase your cost exponentially.
- Duplicate contact records by themselves are a cardinal sin against data integrity. Not only will your Sales Reps log activities in multiple places, your reports on sales and campaign effectiveness will be greatly skewed.
- 2. Related Accounts & Contacts
In summer ’16, Salesforce addressed the need to facilitate a many-to-many relationship between accounts and contacts by releasing “Contacts to Multiple Accounts.” This functionality creates a junction object that allows a single, unique contact record to be related to many accounts, called “Related Accounts and Contacts”.
For the purposes of our example, we have added Related Accounts for each of the East Coast Acme accounts which John Doe supports to his contact record. Unfortunately, the external user tied to John Doe’s contact does not recognize these relationships; as such, account access within your Customer Community will not be impacted. Therefore, while this feature meets a system of record need, it does not meet our requirement to provide access to multiple accounts to external users.
- 3. Sharing Sets
Sharing Sets allow records to be shared dynamically based on some common criteria. In our case, we could set up a Sharing Set for the external user profile which is based on the account object, and leverage the parent account field as common ground – if the external user’s parent account matches the parent account on a given account, access is granted (including case access):
Given the Sharing Set we have built, John Doe will have access to any account which shares the same parent Acme Corporation – Corporate. Therefore, John Doe will be able to create support cases for any account within the Acme Corporation hierarchy. Success! While this method has granted our external user access to multiple accounts, it is important to consider the implications of your organizations specific hierarchy model. Note that, above, one parent account sits on top of all Acme Corporation accounts. Remember, John Doe only needs to open support cases for Acme’s East Coast accounts. We have inadvertently granted too much access! To truly meet our requirement, we would need to implement a secondary hierarchy level involving East and West Coast parent accounts. When leveraging Sharing Sets, pay attention to how your organization’s account hierarchy will impact access.
- 4. Apex-Managed Sharing Rules
Let’s say that your organization does not want to modify its current account hierarchy model, or that your organization does not currently use any account hierarchy. Apex-managed Sharing Rules offer the greatest flexibility in this instance, because any criteria can be used to grant access on a record-by-record basis. In our example, we have created our own custom “Support Users” junction object to facilitate a many-to-many relationship between accounts and external users:
A record of this custom object can be created for any account + external user combination to establish a relationship between a user and the accounts to which he or she needs access. A custom sharing reason is then established based on the custom Support User object; our Apex is then fired when the record is saved, granting access for the account specified to the external user specified. In the example pictured above, saving this record grants access to the Acme Corporation – Hartford account (including any related cases) to external user John Doe.
Here’s how this works in our use case: John Doe needs access to create support cases from within your Customer Community on behalf of six different accounts; that is, each of Acme Corporation’s East Coast accounts. With our Apex in place, someone within the organization (an internal user) simply creates a Support User record for John Doe against each of those six accounts. Here’s what it looks like for the Acme Corporation – Hartford account:
Once saved, access is granted to the specified external user (John Doe) to the specified account (Acme Corporation – Hartford). While this solution may seem more labor-intensive than the aforementioned Sharing Sets, it provides the level of granularity necessary where there is no account hierarchy of which to take advantage.
To reiterate, there are a few ways to grant your Customer Community users the access they need. Each method, however, is only appropriate in some scenarios given your current Salesforce instance. Here is a helpful chart which overviews the solutions we’ve explored in this post:
|Solution||Appropriate Use Case||Pros||Cons|
|Duplicate Contacts/ External Users||None||None||Compromise data integrity within your instance
Poor user experience (both internal and external)
|Related Accounts & Contacts||System of record only||
Facilitates one-to-many relationship between contacts and accounts
Does not grant additional account access – not a valid solution
Existing account hierarchy model matches access use case
Dynamic based on existing hierarchy model
No additional burden on the internal users
Grants too much access depending on use case
|Apex-Managed Sharing Rules||
Sharing criteria is unique and situational
No existing account hierarchy model in place
Existing account hierarchy model does not match access use case
Not reliant on account hierarchy model
Excellent user experience
Additional Apex load (Minimal depending on your instance)
Requires additional effort by internal users as compared to sharing sets
If you would like to learn more about Salesforce Customer Communities, or if you need assistance solving your Customer Community challenges, contact email@example.com
Justin joined Apps Associates with five years of in-house Salesforce administrative experience within the Renewable Energy industry. He hails from Denver, Colorado (Go Broncos!) although he was born and raised in Sacramento, California. In his spare time, he enjoys volunteering, cooking, and all four-wheeled things fast and loud.