Salesforce Communities exists to connect your company with outside entities and encompasses two categorical options: Customer Communities and Partner Communities. Generally speaking, Partner Communities offers far more extensive sharing rights for Salesforce objects.

In this post, we’ll shed some light on the differences between the two, covering the sharing capabilities in Customer Communities while providing some tips for maximizing those capabilities to get the most out of your subscription. You should familiarize yourself with these sharing capabilities for two reasons:

Licenses: You’ll want to ensure you purchase the right licenses from Salesforce.com (if you have yet to make that decision).

Configuration: You’ll want to understand how to properly configure sharing if you do have Customer Community license.

Let’s look at a hypothetical scenario for reference as we walk through configuration options:

– You’ve set up a customer community

– Your community includes the case object

– A customer-created case is always assigned to an internal user

– The customer who created a case is set as the contact on the case

– You want all contacts from the same account to be able to edit any case submitted by a colleague

Organization-Wide Defaults

Organization-wide defaults apply to your Customer Community Users. Whether you set an object’s default to private, public read only, or public read/write, that sharing model will extend to customers. Of course, you’ll still need to provide at least some CRUD level of access to the object for it to be relevant; if a user cannot access an object, a sharing default of private vs. public read/write will have no bearing on that user.

In theory, you could provide public access to either cases or contacts. However, doing that would almost never make sense for an organization. Think about it—you would be providing each of your customers’ visibility into all contact and case records for all of your other customers. Assume your organization-wide default for both objects is private.

Sharing Rules

In your internal org, you can easily create a custom sharing rule based on ownership or defined criteria to extend the ability to view or edit records to additional users or groups of users. This is available in Partner Communities.

However, you cannot create sharing rules in a Customer Community. Users with Customer Community licenses do not have roles and cannot be added to Public Groups. Take that information and you have an incompatibility between Sharing Rules and your Community Users.

Sharing Sets

To mitigate the deliberate, but potentially debilitating gap in the sharing functionality between Customer and Partner Communities, you can create one or more Sharing Sets here: Build > Customize > Communities > Settings > Sharing Sets. Scroll down to the “Sharing Sets” section and click “New”:

The first key piece to understanding how Sharing Sets work is that no more than one Sharing Set can be created for each available profile. You cannot create multiple Sharing Sets that provide different access and apply both to the same profile. Go ahead and set your label and description for your Sharing Set. Next, select one or more profiles for this Sharing Set to apply to.

On to the fun part. Here, you’ll need to select the applicable object. In this case, you’ll want to select Case and move it to “Selected Objects.” Go ahead and click on “Set Up” next to Case and the Access Mapping for that object will appear.

As stated before, the implicit assumption is that you want to provide Read/Write access to all of the submitting Contact’s colleagues. To do this, you will want to share the Cases to which all Contacts on the submitting User’s Account has access. In other words, provide access to all Contacts where his/her Account = Case Account. Here is the configuration:

Success! You can see that the Sharing Set we created provided Read/Write access to all of John’s colleagues.

This is actually just the first part of Sharing Set functionality. In Spring ’14, Salesforce.com provided the ability to reference related fields via Lookup and Master-Detail fields. Previously, you could only reference fields on the object itself. This ability to traverse related objects increases the sharing capabilities of Customer Communities.

We’re here to help with these technical aspects. Contact us now!