Start tracking your progress
Trailhead Home
Trailhead Home

Create Community Users and a Sharing Set

Learning Objectives

After completing this unit, you’ll be able to:
  • List the main differences between community licenses.
  • Assign the correct license type based on the community member’s needs.
  • Create a community user.
  • Use sharing sets and share groups to control access to community member-owned records.

The Skinny on Community License Types

Erica knows the purpose of the Cloud Kicks community and has gathered key resources. Now she wants to know how to share information with community members in a safe and effective manner. She also wants to know the ins and outs of each license type, so she can make a decision on what types of licenses to purchase. Licensing and sharing are intricately woven in the Salesforce communities world, so it’s good to see how they relate.

Thankfully, Erica has completed the Trailhead Communities Basics and Data Security modules. She has also watched the Who Sees What video series multiple times, so she’s familiar with Salesforce’s sharing model. And she can always bring the tough questions to Linda, the company’s Salesforce admin, who’s a font of knowledge of all things sharing-related.

No one wants to share internal data that is supposed to stay private with the outside world, so understanding sharing is imperative. Give community members access to knowledge articles so that they can resolve their issues quickly? Sure. Give access to company sales practices and numbers? No way.

Before we delve into sharing, let’s try to pin down when you need to use a community license.

Use this handy decision tree to see which license you need.

A screenshot choosing community licenses

When do you need each type of license? Ask yourself some questions.

Do you have a large B2C community with millions of users? You probably need some Customer Community Licenses.

Do your community members need access to:

  • Reports and dashboards
  • Delegated admin
  • Content libraries
  • Records across accounts

Then you probably need Customer Community Plus Licenses.

In addition to the above, do your community members also need access to:

  • Leads and opportunities
  • Campaigns

Then you probably need Partner Community Licenses.

For example, Erica is hoping to assign some Cloud Kicks community members as delegated admins of the community. With delegated admins, Erica has helpers who can create users and do simple troubleshooting for community members.

The Customer Community Plus license, with its increased access, is right for these delegated admins.

The remaining community users access the community with Customer Community Licenses.



Communities licenses are associated with users, not a specific community.

If needed, Erica can move users with these licenses between communities. Or she can create one community and use different licenses and permissions to give each individual member a different experience.

Here’s another way to think about it: Your community is like an airplane. Each passenger has a different type of ticket (license), and therefore, different levels of access. They’re all together on the same ride, but each person has a slightly different experience based on how much the ticket cost.

Customer Community Licenses get a basic pass, just like an economy ticket. Customer Community Plus Licenses get more access, like business travelers. Partner Community Licenses? Well, they get way more access, pretty much like first-class travelers.

After weighing the options available, Erica and Linda advise their CIO, Yanik, to pick a combination of Customer Community and Customer Community Plus licenses for their customer community.

With both types of licenses accessing the community, Cloud Kicks has the flexibility of giving some members more permission as needed. For instance, they can appoint external community members as moderators or give them limited delegated admin privileges.

External Sharing Settings

Now that Erica’s got a good handle on license types, she has to figure out how those licenses work when it comes to sharing data.

Setting an external sharing model helps Erica with her goal of sharing information with external users. External org-wide defaults allow her to set a different level of access for external users than what she has for internal Salesforce org users.

The following objects support external org-wide defaults.

  • Accounts and their associated contracts and assets
  • Assets
  • Campaigns
  • Cases
  • Contacts
  • Individuals
  • Leads
  • Opportunities
  • Orders
  • Users
  • Custom Objects

External org-wide defaults are enabled by defaults for all orgs. You can check access levels in Sharing Settings.

You can set one of the following access levels for each object.

Access Level Description
Controlled by Parent Users can perform actions (such as view, edit, delete) on a record on the detail side of a master-detail relationship if they can perform the same action on all associated master records.


For contacts, you must set Controlled by Parent for both the default internal and external access.

Private Only users who are granted access by ownership, permissions, role, hierarchy, manual sharing, or sharing rules can access the records.
Public Read Only All users can view all records for the object.
Public Read/Write All users can view and edit all records for the object.


The default external access level must always be more restrictive or equal to the default internal access. When you’re setting up your external org-wide defaults, you can’t give your community member more access to an object than you do to an internal Salesforce org user. A best practice is to always have external org-wide defaults set to private.

Nuances of Sharing Using Customer Community Licenses

Community members who access the Cloud Kicks community using a Customer Community License have a much more limited level of access to the community’s objects compared to other community license holders and Salesforce internal org users.

Why? Because these license holders do not have roles within Salesforce, so they can’t take advantage of role-based sharing. And what, you may wonder, is role-based sharing? It’s any data visibility in Salesforce that requires the use of a role (such as sharing via role hierarchies).

By default, members with a Customer Community License can see only their own records, such as the cases they file with support. They can’t see anyone else’s cases in the community.

But Customer Community License holders can access records associated with their accounts or contacts by using sharing sets. Are you scratching your head yet? Let’s break it down.

First things first: What in the world is a sharing set? A sharing set gives community users access to records that are associated with their accounts or contacts based on their user profiles.

Great, but what does that really mean?

Meet Jess, a member of the Cloud Kicks community with a Customer Community License. Her shoes start wearing out much more quickly than she expected, so she logs a case with support through the community. The next time she logs in to the community, she can access that case and check its status because she owns it.

Let’s say that instead of logging a case herself, Jess calls Cloud Kicks Support. Mike, a support agent, logs a case for her. Can Jess access that case? She can, but only if the community admin has set up a sharing set that gives her access to cases associated with her contact record via her profile.



The admin can set up only one sharing set per profile per object.

Linda helps set up a sharing set, which she can do after enabling communities in her org.

  1. From Setup, enter Communities in the Quick Find box, then select Communities Settings.
  2. Select Enable communities.
  3. Enter a unique name for your Lightning Platform domain.


    Keep in mind that you can’t change your Lightning Platform domain name after you enable your community. To minimize confusion, companies usually use their company name as the domain. Make sure to coordinate with your marketing team and executives to set up a unique name for your business. If you set up more than one community, you can append the community name to the URL to differentiate between them.

  4. Click Check Availability to make sure the domain is available.
  5. Click Save, then OK.

For the purposes of this module, we’re allowing Cloud Kicks to use standard community profiles to set up community users. Let’s enable the setting that allows for you to do this.

  1. From Setup, enter Communities Settings in the Quick Find box, then select Communities Settings.
  2. Check Allow using standard external profiles for self-registration and user creation.
  3. Click Save.


The best practice here would be to clone the Customer Community User profile, and go through all the user permissions with a fine-toothed comb to ensure that all the settings are ones that you want.

Onwards to sharing sets then.

  1. While still in Communities Settings, scroll down to the Sharing Sets related list, and click New.
  2. In the Sharing Set Edit page, fill in the Label and Sharing Set Name fields.
  3. Enter a description.
  4. Select the profiles of the users to whom you want to provide access, such as the Customer Community User Profile.
  5. Select the objects you want to grant access to. The Available Objects list excludes:
    • Objects with an organization-wide sharing setting of Public Read/Write
    • Custom objects that don’t have an account or contact lookup field
  6. In the Configure Access section, click Set Up next to an object name to configure access for the selected profiles.


    Objects with Set Up in the Action column aren’t configured for high-volume portal user access. Until you configure an object, high-volume portal users have limited or no access to its records. For more information on access, see About High-Volume Portal Users.

  7. Grant access based on an account or contact lookup:
    • Select a value in the User drop-down list to determine the account or contact lookup on the user.
    • Select a value in the Target Object field to determine the account or contact lookup on the target object.

    For example, to grant access to all cases associated with an account identified on the user’s contact record, select Contact.Account and Account respectively.



    Both selected fields must point to either an account or contact. For example, Contact.Account and Entitlement.Account both point to an account.

  8. Choose an access level of Read Only or Read/Write. (If the object’s organization-wide sharing setting is Public Read Only, then only Read/Write is available.)
  9. Click Update, then click Save.

Now let’s pretend that Jess has made a bevy of cases. Mike, our trusty support agent, needs to access all of them. How can Mike see Jess’s cases?

With a share group, of course.

Awesome. Now what in the world is a share group?

Simply put, a share group allows you to share records owned by Customer Community License holders with internal and external users in your community.

Why is a share group needed when various record access capabilities are available in Salesforce? Most of those capabilities (record access via a role hierarchy, criteria-based sharing rules, manual sharing, team sharing) are not available for the Customer Community License because they require a role within the Salesforce hierarchy.

Customer Community Licenses can’t have roles.

Share groups fill in the gap by letting you open up record access of records owned by Customer Community License holders.

Learn more about sharing in communities in the video series Who Sees What in Communities.

Create a Community User

After you enable communities in your org, Salesforce adds specific actions to your account and contact page layouts in Lightning Experience so that you can create customer users.

Erica wants to create some customer community users. It’s a straightforward process: from the contact record, she selects Enable Customer User from the menu.


In order to see the Enable Customer User option, your Trailhead Playground user (yes, that means you!) needs to have a role assigned. Edit your user record to assign yourself any role in the role hierarchy.

She then edits the user record with the following

  • Email: [your email address]
  • Username: [unique username in an email format]
  • User License: Customer Community
  • User Profile: Customer Community User
  • Select the Generate new password and notify user immediately checkbox. (That way you can log in as the customer user.)
  • Click Save.

And voila, a customer community user is born.

Trust in Trust

Yes, sharing and licenses in communities can be a lot to wrap your head around. Really, though, it all comes back to Salesforce’s biggest value: trust. The various levels of security keep your data safe, even as you decide to share some of it with community members.