A Salesforce Customer Community is a dynamic product which allows your employees, partners, and customers to connect, collaborate, and self-serve. Of course, no matter how elegant in appearance, a Salesforce Customer Community is, at its core, good-old-fashioned Salesforce functionality and data. Specifically, your Community hinges largely upon Chatter and Service Cloud functionality; the latter of which presents accessibility challenges to organizations who utilize the common Salesforce Account Model, which entails a hierarchy of accounts for single customer organizations. This article will explore this challenge as well as several ways to solve it.
The Case for a Customer Community
If your organization is looking for a way to provide better service to your customers, a Customer Community may be for you. A Customer Community creates a space for customers to collaborate with one another by posing questions about your products to other customers, as well as your partners, via Salesforce Chatter. It also puts your stout knowledge base at the fingertips of your customers with a simple, yet comprehensive search. One of the biggest values that a Customer Community brings to your bottom line is in reducing the burden on your friendly customer service team by curbing the volume of incoming service cases. While Chatter-based collaboration and a searchable knowledge base will go a long way toward achieving this goal, your customers will still need to raise their hands for help. Since a Customer Community is one and the same with your organization’s Salesforce instance, enabling case creation from within your Community is a no-brainer. This way, your customers can raise and manage their cases online instead of bogging down your customer service team’s phone lines. With a Customer Community, you can have a robust strategy for reducing service overhead and providing a better experience to your customers, all while using familiar Salesforce tools.
First, we must understand a little bit about Customer Community users. These users (your customers) are different than Force.com users (your employees). Your customers will use external user licenses based on contact records. The relationship between contacts and external users is one-to-one. The relationship between contacts and accounts is also one-to-one. Therefore, the relationship between external users and accounts is one-to-one. For example, let’s say Acme Corporation, a customer of yours, is a nationwide construction company. John Doe works for Acme in Waterbury, CT as an IT/IS Support Engineer. He is responsible for maintaining your products for Acme’s East Coast area locations and has been an active user of your new Community:
Note that John Doe’s contact record relates directly to his “Customer User” and is also related to the Acme Corporation – Waterbury account via the standard contact-account relationship.
Next, it is important to understand the typical account hierarchy. Let’s say that your organization also uses the standard Salesforce Account Model, wherein your customers may have a hierarchy of multiple account records representing multiple sites or bill-to locations. For example, Acme Corporation may have a parent account representing their headquarters, as well as twelve children accounts – one for each of their twelve locations across the country.
Recall that John Doe is responsible for maintaining your products for Acme’s East Coast locations. As such, he needs to open and manage cases for those corresponding accounts. Because John Doe’s external user and contact records are related to a single account (Acme Corporation – Waterbury), he is only able to create and manage cases as they pertain to that account. He is unable to do anything related to any other Acme Corporation account from within the Community. Note below, as John opens a new case, he is unable to modify the “Account” field, which defaults to his primary account:
As is most often the case, there are many ways by which we can solve this problem. Here, we will outline the various methods which may be used.
- Related 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. In theory, it’s conceivable that Community-level access should be influenced by these relationships. (Sneak peek – we will see that this is not possible.)
- Sharing Sets: Sharing Sets allow records to be shared dynamically based on some common criteria. For example, account and case access can be granted based on the parent account of both an external user and account. In our case, if the parent account to John Doe’s contact is the same as the parent account to the account listed on a case, he would be granted access to that case.
- Apex-Managed Sharing Rules: Apex-Managed Sharing Rules programmatically share records based on a custom reason. Think of it as Sharing Sets with more flexibility. There are some restrictions to this that we will dive into in Part II, as well as a need to know basic Apex coding. However, Apex-Managed Sharing facilitates sharing based on criteria beyond what Sharing Sets can offer.
You can read Part II here, in which we’ll explore the viability of, and the pros and cons to each of the aforementioned solutions.