Salesforce has numerous tools to control and manage the level of access granted to both standard or platform and Experience Cloud users. Luckily for administrators, there is significant cross-over between the two sets of access. In this article, we’ll discuss the common sets of controls, the Experience Cloud specific sets of controls, and how a custom solution can help ease access considerations and empower partners and customers to manage their own account’s team.
Permission Management
Profiles
Profiles are the first consideration when setting up users. For those of you who are not familiar with Salesforce access controls, profiles give a huge amount of customization to what users can create, read, edit, and delete. They can also control certain other features, licenses, and defaults that affect the user’s experience. Before the introduction of Permission Set Groups, the common advice given by architects and administrators is that you want to try to group common types of users into specific profiles to grant a base-level set of permissions. For internal Salesforce administration, this is still true. However, for Experience Cloud sites, we recommend creating a trimmed-down Profile that will provide the least amount of access necessary to access your site. This approach creates flexibility and modularity as different types of users grow and change on your site.
Permission Sets
Now that you’ve created a base-level Profile for your Experience users, Permission Sets are great tools to enhance users’ level of access for specific pages, tabs, and additional objects or fields. Generally, we recommend using a permission set for each feature of your site. For example, if you have Partners who will be entering Leads into the system, you might create a Permission called “Company Name Portal – Lead – Create and Edit.” As you might infer, this permission set grants access to create and edit Leads. The sky is the limit with how many permission sets and modules you want to give access to. It is important to remember that the highest level of access will win if you assign two conflicting permissions to a user. This means if one has Delete access and the other does not, the user will have Delete access. One final recommendation is to avoid using the License picklist. In our experience, this has pigeonholed us into having to create a new Permission Set from scratch when we would like to create similar functionality for a user of a different license type.
Permission Set Groups
If you have a complex data model with many different levels of access required, the number of permission sets you will make may seem overwhelming at first. You might ask yourself, “How will I be able to manage every single one of these and assign them to the right people?” Depending on the size of your organization or portal, this very well could become a full-time job if you’re not managing it properly. Earlier, we discussed the benefits of modularity in utilizing permission sets instead of a profile for each potential role at your company. That was because we recommend the creation of Permission Set Groups. This feature is something you may not already be familiar with as a Salesforce Administrator. Permission Set Groups were only just released in the Spring ’20 release. A Permission Set Group offers administrators an easy way to, you guessed it, group permission sets. The two trains of thought on creating Permission Set Groups are through activity or function-based groups or role-based groups. The decision is likely somewhere in between. We all know there are power users who may be in one role but can and should be trusted to perform additional tasks. By creating base-level role Permission Set Groups and additional function-based groups, you can empower your company’s SFDC team to handle the requests for access thrown their way.
Custom Development
If you’re lucky enough to have a Salesforce Developer on your team who is skilled in Aura or Lightning Web Component development, you may be able to delegate user management in Experience Cloud directly to your clients or partners themselves. Organizing the Profiles, Permission Sets, and Permission Set Groups thoughtfully and logically sets up the foundation to be able to build a component that allows for designated users at an Account to create, disable, and manage the permissions of their own users. We’ve built a few of these components for our own clients and have been told that it is the #1 timesaver of anything we’ve built for organizations utilizing Experience Cloud. The sky is truly the limit when you start delving into custom components to manage user permissions. Language, locale, contact information, Manager, Roles, Permissions… it truly empowers your users and makes the onboarding process as a customer or client that much smoother as you train-the-trainer and provide the tools they need to succeed in whatever your portal is used for.
Audience Management
What are Audiences?
Many of the readers of this article will be familiar with the concepts discussed earlier. Profiles, Permission Sets, and Permission Set Groups are all standard Salesforce functionality that function the same regardless of license type. If you’ve never used Experience Cloud before or you’ve only dabbled in basic sites, you may not be familiar with the concept of Audiences. Audiences allow for unique experiences based on several factors. You can utilize the field on the User and their Contact or Account. One example of this could be using the Industry picklist to show industry-specific information dynamically. Audiences can also utilize Roles, Profiles, Custom Permissions, and numerous other identifiers to help make your Experience truly powerful and customized for the current user.
Audience Assignment
There are two ways to assign Audiences to customize a User’s Experience. The first way we’ll talk about is called Page Variations. Imagine this… you’ve built a beautiful homepage rich with features, content, and information. You find out that it doesn’t apply to everyone, and you’ll need to show a completely different set of features, content, and information. Instead of starting from scratch, you can copy your existing page into a new Page Variation. This allows you to tweak the experience based on Audience so that users have a totally different view than other audiences might. On the flip side, you find out that one of your Audiences doesn’t need to see a specific bit of information you’ve put on the home page. Instead of creating a wholly different page for them, you can simply apply component-level visibility to that Rich Content Editor or HTML Editor section. This flexibility allows you to see everything that one might see all on one page. We recommend using the component-level visibility method when there are only slight changes. One thing to be aware of is that you can only assign one Audience to a component or page variation. This can lead to some interesting strategies for creating and naming your Audiences. Our recommendation is to use higher-level groups like Roles, Partner Types, or Industries for Page Variation Audiences and more specific Audiences for component-level visibility. Of course, this is a generalization, and you should work with a Business Analyst and Solutions Architect to determine the best fit for your company.
Conclusion
The Salesforce ecosystem is huge, and the numerous ways to customize it are always growing and changing. This article is not comprehensive, even for all the existing features. We could, and probably will, write another entire article devoted to Sharing Rules, Sharing Sets, and Apex sharing, which can have a huge effect on the visibility of records even if the user has permission to that object via profiles or permissions sets. There are also Restriction Rules which were just made generally available in the Winter ’22 Release. Our point is: Salesforce is complex. Make sure you have a Partner who understands these complexities and can help you navigate through them to make sure your Experience Cloud site is the best it can be to foster adoption and ease of use.
