Permissions in Salesforce can be dizzying. Between licenses, profiles, and permission sets, there are multiple ways permissions can be assigned, and multiple considerations you should take into account. And there are SO MANY permissions that can be set, which means there are equally many ways they can trip you up. I’m going to break it down and demystify it for you so you can conquer Salesforce permissions.
Contents
- Salesforce Permissions
- The Key Idea
- Types of Permissions
- Licenses
- User Licenses
- Permission Set Licenses
- What My License Enables
- Profiles and Permission Sets
- Profiles
- Permission Sets
- Permission Set Groups
- Considerations
- Keeping It Clean
- Side Effects
What is a Salesforce permission? A permission is a setting that provides a user with the capability to do something in or with Salesforce. That “something” may be, for example, sending an email, editing a record, or assigning permissions to other users. (Note that editing a record also requires the appropriate ownership or sharing settings, which is part of a topic I’ll cover in a future post on sharing).
The Key Idea
The key thing to understand about permissions is that they can be granted in a variety of ways, but only revoked by removing all the different ways in which they were granted. That’s confusing, so let’s unpack it.
Revoking Permissions
What I mean is that you can’t check a box to deny a user the ability to do or access something. In other words, you can’t revoke a permission with an explicit “revoke” setting. Instead, you must find all the ways in which it was granted and remove them one by one. That can be a lot of work.
Granting Permissions
Since revoking permissions is a pain, we must be careful how we grant them. Any time you are granting permissions to large sets of users at once, grant only the minimum permissions you want them to have. Then layer on additional permission grants to users individually or in smaller groups by using structures like permission sets, discussed below.It’s also important to keep it clean. Since there are multiple ways to grant a permission, we want to have a logical and easy-to-follow approach to how we grant them. That will make it easier to know how to go about changing and revoking them when necessary, as well as making it easier for another admin in your org to do so. I’ll go over this in more detail below once I introduce some key concepts we’ll need to understand first.
Types of Permissions
There are bunch of different types of permissions you can enable in Salesforce.
User Permissions
User permissions, sometimes labeled app and system permissions, are the most general class of permissions. Anything that doesn’t fall squarely in another permission type is housed here.
Object
Object permissions govern the base-level access a user enjoys to records within a Salesforce object, which is the term Salesforce uses for data table. Example object permissions include read, edit, and create. As I noted earlier, record ownership and sharing also play a part.
Field
Field permissions govern the base-level access a user has to certain fields within data records. Examples of fields in the User object include a user’s name or email address. Field permissions are like object permissions, constraining the ability to for example read or edit the field for related records. And record ownership and sharing again play a part.There are a bunch of other types of permissions that I won’t describe here, but are managed similarly. They include:
- Assigned Apps
- Tab Settings
- Record Type Assignments
- Apex Class Access
- Visualforce Page Access
- External Data Source Access
- Service Provider Access
- Custom Permissions
Permissions are closely related to licenses. Licenses are what you purchase from Salesforce to be able to use various features in their system. They are how Salesforce charges for its software and services. If a user has a license to do something, it doesn’t necessarily mean the ability is turned on for them, but it does mean that it could be. There are two types of licenses: User Licenses and Permission Set Licenses. Salesforce also sometimes refers to the latter as Feature Licenses.
User Licenses
User licenses are what you buy to add a new user to your Salesforce org. In other words, if you have ten people using Salesforce at your company, you need to have ten user licenses. Each user license typically allows a large number of related permissions.When you purchase user licenses, they often must represent a similar level of service. For example, if you’re using Salesforce Sales Cloud, you cannot have some users on a Lightning Enterprise license and others on a Lightning Unlimited license. You basically are forced to upgrade everyone together to Lightning Unlimited.
Permission Set (aka Feature) Licenses
Permission set licenses are a way to purchase smaller groups of features for your users. They’re also assigned to users in a different way than user licenses, which I’ll discuss below.
What My License Enables
When you buy a license, Salesforce provides you with documentation on what the license contains, usually by sending you a PDF file. This is a high-level list that doesn’t map explicitly to the individual permissions you are granted in Salesforce. It’s similar to what you’ll find in Salesforce online documentation, for example what you’ll find by drilling down here: https://www.salesforce.com/editions-pricing/overview/. Understanding which individual permissions are included takes a little guesswork if all you do is look at the documentation. It’s clearer within the Salesforce web interface because Salesforce doesn’t let you do things you’re not allowed, such as assigning a permission to a user who doesn’t have the necessary license for it. So if you can’t see it a permission or assign a permission, you probably don’t have one of the licenses that enables it.It’s also helpful to note that Salesforce changes licensing structures and prices from time to time. That means your Salesforce account rep is the best source for current licensing options.
Now that we understand licenses, we need to go over how they’re used. Licenses are associated with users through profiles and permission sets. Licenses dictate what users might be allowed to do, whereas profiles and permissions sets dictate which of those capabilities are actually enabled for the users.
Profiles
Every Salesforce user must be assigned a profile. The profile grants the user privileges to use certain Salesforce features through its connection to a user license. Every profile must be associated with one user license, no more, no less. And every user must be assigned exactly one profile. So there’s a 1:1:1 mapping of user license to profile to user.Profiles are designed to be assigned to general classes of users that share many permissions in common. For example, your entire marketing team might all be assigned the same profile that provides them use of the Salesforce Marketing Cloud.Since profiles are assigned broadly across many users, set them to include the minimum permissions you’d like those users to hold. You can always grant individual users more permissions by using permission sets, discussed below.There are two types of profiles, standard and custom.
Standard Profiles
Standard profiles are created automatically by Salesforce. Each standard profile is born associated with a particular user license and by default enables all of the permissions that the user license grants. In other words, everything that can be turned on, is turned on. Standard profiles cannot be changed, however, so you can’t turn their permissions off. For that, you need a custom profile.
Custom Profiles
Custom profiles are created by you, the Salesforce admin. You pick which user license is assigned to the profile, and you also pick which permissions the profile enables, among those allowed by the assigned user license. Which ones are allowed? Well, whichever permissions are visible and editable on the profile’s detail page are allowed. Unlike standard profiles, you can edit the permissions in a custom profile to set them to on or off.
Permission Sets
What if you want different sets of permissions for users assigned the same profile? Well, that’s where permission sets come in. Permission sets are exactly what they sound like – sets of permissions. While it’s best to go with minimum desired permissions settings in profiles since they are broadly held, you may want to grant greater levels of permissions with permission sets since they are more likely to be assigned to a smaller number of users at a time.Permission sets can be assigned to any user you like, provided the licenses are set up in a way to allow it. Let’s get into what I mean by that.
Permission Sets and Licenses
Unlike profiles, permission sets aren’t necessarily assigned a single license. They may be given a single license, they may be given multiple licenses, or they may be given no licenses at all. If the permission set is associated with any licenses, the users assigned the permission set also gain its associated licenses. It also means the permission set is restricted to permissions allowed by those licenses. If instead the permission set is not associated with any licenses, you can set whichever permissions you like in the permission set, but you can only assign the permission set to users who hold all the licenses necessary to enable those permissions, either from their profile’s user license or from other permission sets that include licenses.
A recent Salesforce feature is the addition of Permission Set Groups to the mix. A permission set group allows an administrator to group permission sets together and assign them in a bundle to users. This can simply both assignment and management of permissions.To provide an additional level of control, permissions in these sets can be “muted” by the permission set group. A muted permission is not enabled by the permission set group for its target users.
Now that we’ve gone over permissions, licenses, profiles, permission sets, and permission set groups, let’s discuss some tips for using them.
Keeping It Clean
I’ve already laid out the key idea that permissions are granted in multiple ways but only revoked by removing all the ways they were granted. I mentioned that keeping it clean is important because of this key idea. To keep it clean, we don’t want to have more different profiles and permission sets floating around than are necessary. With a large number of them, there’s more to understand and look through when figuring out how to best grant or revoke a permission. It can get very unwieldy.Since there are multiple ways to set up your profiles and permission sets, pick the arrangement that is clearest for your users’ needs while requiring the smallest number of profiles and permission sets. It should be easy to follow not only by you, but also by your colleagues or successors who have to take over administration.
Side-Effects
When you assign profile or permission set to a user, keep in mind that they receive every included permission. If you’re looking to grant them something particular, there may be a bunch of extraneous permissions they also receive. It gets harder to judge when you realize some of those extraneous permissions might already be granted to the user elsewhere, so they aren’t extraneous after all. Determining whether the user already has a permission is a time-consuming task that requires sifting through all permissions granted elsewhere.When you modify a custom profile (remember standard profiles can’t be changed) or a permission set already assigned to a user, you can be sure you aren’t granting the user any extraneous permissions in the process. On the other hand, any changes you make affect all other users assigned the same profile or permission set. For them, a change that grants a new permission might be something they shouldn’t get. I say “might be” because again, they could already be granted that permission elsewhere. And again, checking that for each of them is a time-consuming task, because you have to look through all the profiles and permission sets for affected users to see which permissions they already have.
Back to Top
