3 Things I Wish I Knew About Salesforce Community Cloud Prior to Implementation
post-template-default,single,single-post,postid-1135,single-format-standard,bridge-core-2.2.2,qode-page-transition-enabled,ajax_fade,page_not_loaded,,qode-title-hidden,qode_grid_1300,footer_responsive_adv,qode-content-sidebar-responsive,qode-theme-ver-28.5,qode-theme-bridge,qode_header_in_grid,wpb-js-composer js-comp-ver-6.1,vc_responsive,elementor-default,elementor-kit-2761

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!

  • Pratima Shrivastav
    Posted at 08:34h, 06 July Reply

    Thank you for sharing this. i find this extremely helpful. Can you please guide me on how I can get started on my own project on Communities to learn this?

    • Paul Fischer
      Posted at 09:45h, 08 July Reply

      Hi Pratima, I’m glad you found this post helpful. You can setup a new Community in your sandbox or developer org. From the setup menu you can go to Communities–>All Communities and can click “New Community”. From there you can start to build your Community and play around with the features. Let me know if you have any more questions!

  • Guillaume
    Posted at 13:13h, 04 October Reply

    Hi Paul,

    In fact, I’m trying to do both setup you are mentionning…
    1. Show cases assigned to a queue to the community user: I was able to do it with the same solution you mentionned
    2. Show cases from child accounts to the parent account: I’m able to do it, but since we can only set one Sharing Set/access grant per object, I’m not able to apply both rules.

    You said you were able to complete the sharing of child cases to parent account.Were you able to keep the other sharing in the same time or not?

    Thanks a lot

  • Phu
    Posted at 14:03h, 30 November Reply

    Community Users of a Parent Account to be able to view the Cases that were logged by Community Users of the Child Account.

    How did you set this up? Kindly, please email me how you set it up above.

  • Meredith
    Posted at 20:32h, 03 January Reply

    Thank you, Paul! This is helpful. One question I’m hoping someone might be able to help me with. I’m not seeing the “Article Management” section in the sidebar menu when I’m in my Community Workspace under Content Management. I’ve confirmed I have the Knowledge User checkbox checked and the Manage Salesforce Knowledge permission. Thanks!

  • Mitch
    Posted at 10:47h, 13 June Reply


    A little late to the party, but this is a terrific article. Thanks for the post! I’ll be poking around your site for more of this. Well done. Very much appreciated.

  • Andy
    Posted at 08:44h, 26 September Reply

    I am looking to see how you set up the list views for the Contact to view all Account cases.

    • Paul Fischer
      Posted at 08:51h, 08 October Reply

      Hi Andy, I just sent you an email with how to use a Sharing Set to fulfill this requirement. Thanks!

  • Lisa peterson
    Posted at 19:43h, 07 May Reply

    Some great information here thank you for the post! I’m trying to restrict the visibility of contacts that display when using the @mention feature. We would only like the contacts for the account record of the contact logged into the community to display and not show the contacts for other accounts. However we would like the community users to be able to mention our internal employees. When we set the user external default to private they can’t @mention internal employees. Any ideas?

  • Devanaryanan
    Posted at 13:46h, 27 January Reply

    Hi Paul, This post is very useful for me to set up. Now, in my Community, we have a Home page with Case list, Featured Topics and articles. New requirement is to have another homepage for the same users and in that home page we need to have a different set of Topics and articles not the ones listing in the existing home page. It means when i used the topic catalog component and featured topics component I need a different set of topics in the new home page. How can we achieve this ?

  • Emma
    Posted at 02:49h, 07 May Reply

    Hi Paul, Great post to implement a Community and choose the most convenient template and funcionalities.
    One question: When creating a customer community cloud, which way is recommended to create the users: Let them create the user on their own (but I have to link them to existing customer) o create automatically users for all new customers?

  • Davis
    Posted at 10:38h, 02 August Reply

    Hi Paul, thanks for this great post. In #3 you mention needing to install a plug-in so that Case Assignment Rules can work with Experience Cloud / Communities — do you know where I can find this plugin? Thanks!

Post A Comment