02 Jul 3 Things I Wish I Knew About Salesforce Community Cloud Prior to Implementation

I’ve spent the past few months rolling out Salesforce Community Cloud for one of our clients. For those not familiar with Community Cloud it is simply an online portal used to connect with your partners or customers, and which also occasionally publishes articles like https://www.salesforce.com/blog/2019/01/how-to-create-a-customer-centric-experience.html which expounds on how to improve customer service. Community Cloud brings in a lot of other Salesforce features such as the knowledge base, case submission, and Chatter. There are different types of Communities including Employee Community, Partner Community, and Customer Community. Each of these Community types have varying feature sets so you’ll want to ensure you choose the right one. In addition, Communities can be private (login required), public, or hybrid (where certain content is only available to the public).

The Community I recently implemented was a hybrid Customer Community that had both publicly facing elements and private elements that required a login to view. The Community included knowledge base access, Case submission, and chat–which were channels that had already been implemented as part of Service Cloud. The Community extended this service capability to form a collaborative customer hub.

The below items are things I wish I would have known prior to implementing Community Cloud, but have now learned. I hope you find them helpful!

1. The Template You Chooses Matters

Salesforce Community Cloud comes with a number of different templates. It’s important to note that each template is more than just the way the portal looks. They each provide unique functionality and components. You will want to weigh what functionality you require the heaviest when selecting a template. If you like the way one template looks, but it does not provide the required functionality then go with the template the provides the correct functionality. You can later modify the look with HTML components and CSS. This table on the Salesforce help website is useful to understand which features are available in each template.

2. Leveraging Knowledge in Community Cloud is Tricky

Topics in Community Cloud

Salesforce Knowledge works a bit differently in Communities compares to how it functions in other products like Service Cloud. First, Community Cloud has a concept called Topics. Topics is a feature that provides a completely different way to organize knowledge articles in comparison to how articles are organized in Salesforce using Data Categories. The Customer Service template ships with a number of Topics standard components. These components can be dragged onto your page. However, in order for articles to display in these components Topics must be assigned to articles.

There are a few different ways to assign Topics to articles. While in Community Workspaces navigate to the Content Targeting section. In the Topic Management section you can create Topics. To assign Topics to Articles go to the Article Management Section. From here you can search for a particular article and also filter down by Data Category. Add the topic and click save!

There is also the option to have Topics automatically assigned to Articles. You choose the Data Category and Topic mapping. If you want Topics to be automatically assigned based on something besides Data Category then you will need to create a Trigger to automatically assign the Topic. In addition, if you need to bulk assign Topics to articles you can do so via Data Loader. You simply need the ID of the article (Entity Id), topic (Topic Id), and Community (Network Id). Note when inserting the Topic records via Data Loader the object you need to select is “TopicAssignment”.

Now when you use any of the Topic components your Articles will be visible.

Data Categories in Community Cloud

As I mentioned above Data Categories still dictate the underlying article visibility in Community Cloud. In an authenticated (a.k.a. private) Community you can create Profiles for Community Cloud User in the same way you would for internal Salesforce Users. This includes assigning the Community Cloud User Profile Data Category Access (or assigning access to a user via a permission set).

Things are a little complicated when setting visibility for your non-authenticated (a.k.a. public) Community. To set the base access level for Data Categories click the gear settings icon while in the Community Builder. Then click the Guest User Profile.

This will redirect you to the Guest Profile where you can assign the Data Category visibility.

So…what’s the difference between Topics and Data Categories? The Topic is the front-end accessibility for the Community User to be able to view the articles on the page via standard components, while Data Categories are the pre-requisite system security that is required for the article to show up in those components. If the Community User has Data Category access they can use the global search to view an article even if it is not assigned a Topic.

Channel Access in Community Cloud

There’s one more piece to the puzzle when it comes to visibility of knowledge articles in Community Cloud called Channel Visibility. When publishing an article you have a few options of what channels you want that article to be visible to. The channel options are: Internal App, Partner, Customer, and Public Knowledge Base.

Depending on your Community type and which Articles you want to be visible in it you can select your Channels. For an authenticated (a.k.a private) Customer Community you would choose “Customer”, and for a public Community (be it a Customer, Partner, or Employee Community type) you would choose Public Knowledge Base. Note that even if you have an Article published to the right channel the article also needs to have Data Categories assigned, and the user needs to have access to those Data Categories. Conversely, if the article and user has the proper Data Categories assigned, but the article is not published to the correct Channel where the user can see it, then he or she will not have visibility to that article.

3. Understanding How Data Security & the Sharing Model Works is Critical

The data security model in Salesforce is built on 3 core considerations: object access, record ownership, and sharing. Object access is pretty straight forward and defined in the user’s profile where they can be assigned the Create, Read, Edit, and Delete permissions for an object. The same concept holds for Community Users. However, record ownership gets a bit sticky in Communities. For instance, if you have Community User’s creating a Case from an authenticated Customer Community the default owner of the Case will be the Community User. You most likely will want the Organization-wide Default Setting for Cases to be private because you don’t want customers accessing either others’ Cases.

In order for the Case to be resolved it needs to be routed downstream to a Queue or Service Cloud User so they can provide a response. The easiest way to do this is to leverage Salesforce’s Case Assignment Rules that can route the Case to a Queue (note: you’ll need to install a plug-in so that Case Assignment Rules can plug into Communities). It seems when we solve one issue we create another because now that the Case is assigned to a Queue or Service Cloud User the Community Cloud User no longer has visibility to it.

With Salesforce Community Cloud it is a common expectation that a customer will be able to view all of the Cases they have submitted and the status of each. Enter External Sharing Settings and Sharing Sets. External Sharing Settings let you have different org-wide access levels for internal and external (Community) users. You can activate External Sharing by going to the Sharing Settings page and clicking “Enable External Sharing Model”. You’ll then notice a new column called “Default External Access”. Most likely you will want to have your External Sharing Settings for Cases to Private. Then you can begin opening up access via Sharing Sets. With Sharing Sets you’re able to grant access beyond just Case ownership. The most common way is to set visibility based upon the Contact lookup field on the Case.

If you take this approach make sure that the Contact gets filled in on the Case! As a Salesforce Admin you can accomplish this by setting the value for Case.ContactId when the Case is submitted in the Community. You do this by specifying a pre-defined value in your Global Case Action (that is supporting the Contact Support component). In other words, Case.ContactId = $User.ContactId.

There are variations to the Sharing Set setup that was mentioned above. You may want to setup sharing based on the Account field on the Case directly. Sharing sets provide a lot of flexibility with how you can share records in Community Cloud. One requirement we had in our project was for Community Users of an Parent Account to be able view the Cases that were logged by Community Users of the Child Account. This got a bit sticky, but we were able to accomplish it with Sharing Sets (and thankfully did not have to do any sharing through Apex).

Leave me a comment with your top Salesforce Community Cloud tip!