Salesforce Permissions in a Nutshell: Profiles vs. Permission Sets
7 min
Have you ever asked yourself, “How did Salesforce become, and still is, the #1 Cloud-based Customer Relationship Management (CRM) platform in the world?" Imagine a cloud CRM platform trusted by several global organizations to store, analyze, and process their data securely. Of course, that company would undoubtedly have an excellent data security model to gain that much customer trust, right? Indeed, one of Salesforce's foundations of success lies in its emphasis on keeping its platform up-to-date with the latest cybersecurity standards to protect its customers from the ever-advancing techniques of data theft.
How is Salesforce’s Data Security Model built?
.png)
Salesforce’s Data Security Model consists of three logical tiers: Object, Field, and Record-Level Security. It allows flexibility in addressing real-world business use cases without compromising data security. Today, we will mainly focus on object and field-level security, but don't worry; we will tackle record-level security in future articles.
Database 101
To prepare you moving forward, let's go over the three words you'll frequently encounter throughout this article: Object, Field, and Record. If you've ever used Microsoft Excel or learned Structured Query Language (SQL), you'll be familiar with rows, columns, and tables.
- Guess what? Salesforce has equivalents for these words as well:
- Object = “Table”
- Field = “Column”
- Record = “Row”
What is Object-Level Security?
Object-Level Security or object permissions provide data access control at the most superficial level in Salesforce. It lets you specify if the users can create, read, edit, or delete records in a particular object.
- You may also refer to "Create, Read, Edit, Delete" (CRED) access permissions as "CRUD" permissions:
- Create
- Read
- Update
- Delete
However, if you did not specify any action a user can do to an object, they will not be able to execute any actions on it even if you provided access to a field or shared a record of that object; we will get more into detail regarding field-level access later in this article and record sharing in the following article, so hang tight. The minimum permission you can give your users is “Read” access for them to view the records.
- There are also two administrative permissions on top of CRUD or the basic accesses:
- View All - Allows users to view all records regardless of sharing settings for the object
- Modify All - Grants users full administrative rights for the object. Includes having Read, Create, Edit, and Delete access and the ability to transfer and share all records for the object. Caution must be exercised when granting this access.
How about Field-Level Security?
Let’s say you provided your users access to an object but cannot see the fields you created. This is because you might have missed granting them field-level security, also known as FLS.
You can give two accesses:
1. Visible - This allows users to view this field's value and edit its value. Please note that users can only change the field’s value given that you have provided them “Edit” access on the object level.
2. Read-Only - This will enable users only to view the field's value but not edit it.
So, how can I give Object-Level and Field-Level Access?
Here is where the stars of the show come in: Profiles and Permission Sets.
Profile
A Profile defines the base access that can be provided for all Salesforce users. Think of “Profiles” as an entity or persona. For example, you can have a separate profile for Sales users and a different one for Support users.
If you create a Salesforce user, you will be required to assign a profile. Also, a user can only have one profile at a time. But a profile can be assigned to multiple users.
Are there any profile types?
There are two types of profiles: Standard and Custom. A standard profile is a profile already provided by Salesforce, while a custom profile can be created by users based on specific requirements. Object, User, and System Permissions cannot be edited in Standard profiles, so that is where a “Custom” profile comes in.
How do you create a profile?
Salesforce provides standard profiles like Contract Manager, Marketing User, Standard User, System Administrator, or Minimum Access. To create a new profile, you can clone a standard profile and set your custom permissions to that cloned profile. Profiles can be limited to specific features since a Profile is linked to a user license, so keep this in mind when choosing the standard profile you will be cloning.
As a sort of rule-of-thumb, Salesforce admins would usually clone the “Minimum Access” standard profile in creating custom profiles as it is close to being a blank slate while still having few permissions like Access Activities, Chatter Internal User, Lightning Console User, and View Help Link permissions; we will get into more detail regarding these permissions in future articles. This approach is better than reviewing and removing numerous accesses cloned from a standard profile like Standard User or System Administrator profile.
There are permissions you can set using Profiles. These permissions are but are not limited to:
· Object Permissions
· Field Permissions
· Record Type Settings
Record Type Settings specify which record types are available to be selected during record creation. You can also set a default record type that will be pre-selected when the user is presented with the record type selection. Please note that not specifying a record type setting for a profile does not prevent users from viewing a record that has the record type you did not allow for the profile.
· Page Layouts Assignment
Specifies which page layout the user will see. If you have record types enabled for the object, you can set different page layouts per record type.
· Tab Settings
Tab Settings set the visibility of tabs.
There are three options:
1. Default On - The tab appears in the app’s navigation bar and will also be available in the App Launcher in Lightning Experience and the “All Tabs” page if in Salesforce Classic
2. Default Off - The tab does not appear in the app’s navigation bar but will be available in the App Launcher in Lightning Experience and the “All Tabs” page if in Salesforce Classic. Additionally, individual users can customize their display to make the tab visible in any app.
3. Tab Hidden - The tab is not available in the App Launcher or the All Tabs page, is not visible in any app navigation, and is excluded from API responses.
· App Settings
Specifies if the users can see the app from the App Launcher in Lightning Experience or the “All Tabs” page in Salesforce Classic. You can also set a default app which will be the app to be opened when the user logs in to Salesforce for the first time. If the user switches Apps during the session, logs out, and logs back in, the user is taken back to the last App the user was in.
· Session Settings
Sets how many hours a user can be idle before the current session gets logged out. Default is 2 hours. Used to override the org-wide session time-out setting found in Security -> Session Settings
· Password Policies
Admins can specify password expiry, minimum password length, password complexity requirement, maximum invalid login attempts, etc.
· Login Hours
Sets a time range when users assigned to the profile can only log in to the org. For example, if you have all of the Sales users assigned to the “Sales” profile and all have a work schedule of 8:00 AM - 5:00 PM EST, then you can set 8:00 AM - 5:00 PM as the login hours. Before 8:00 AM and after 5:00 PM, the users cannot log in to your org.
· Login IP Ranges
Specifies an Internet Protocol (IP) Range from which the user can log in. The ability to set the Login IP Ranges is beneficial if you only want your users to log in to Salesforce if they use the corporate internet or from a particular location.
· Apex Class Access
· Visualforce Page Access
· Administrative, System, and App Permissions
It contains different permissions that can be set related to reports, dashboards, API access, user management, application management, and more.
Permission Set
Permission Sets give additional permissions to individual users on top of their profiles. You can say that permission sets are add-ons to profiles. For example, let’s say you want to provide access to campaign records to a few users who are managers assigned to different profiles. Then you can assign each manager with a permission set without updating their profiles or even creating a new profile!
- Here are a few points to consider when using permission sets:
- You can remove and add permissions to a group of users, even if they are assigned to different profiles
- A user can have multiple permission sets
- Use Permission Sets when a group of users requires further permissions
- If numerous people need the same permission, consider using a custom profile
How do I create a Permission Set?
Unlike Profiles, you do not need to clone an existing permission set to create one. You can either create a new permission set or clone one - it’s up to you. Start with navigating to Setup -> Permission Sets.
Create new Permission Set
a. Click “New” button when already in the “Permission Sets” list view
Clone an existing Permission Set
a. Click on “Clone” beside the Permission Set you want to clone from
How do I assign a Permission Set to a user?
There are two ways to assign a permission set to a user.
1. Go to the permission set itself
a. Search for “Permission Sets” in Setup and select the permission set you would like to assign to users.
b. Click on the “Manage Assignment” button at the top of the permission set page.
c. Click on the “Add Assignments” button to add users to the permission set and select users to assign the permission set to.
d. Tick the checkbox beside the user and click “Remove Assignments” if you want to unassign the user's permission set.
2. Go to the user record to which you want to assign the permission set. Under the user’s related list, you will find “Permission Set Assignments.” Click the “Edit Assignments” button and select Permission Sets from the Available Permission Set to the Enabled Permission Sets.
Is there any difference between Profile and Permission Set?
Besides the difference in usage, some settings will only be available in Profiles.
Please refer to the comparison below:
Please refer to the table below for sample scenarios using both profile and permission set:
Sounds easy, right?
As we have learned so far, we have different ways of implementing security in our Salesforce organizations. However, while Salesforce has provided various sharing and security capabilities, we must do our part as customers to ensure we implement security in our organizations correctly.
We hope you learned a lot from this article and how to use profiles and permission sets correctly. Stay tuned to the following articles where we delve into other Salesforce permissions!
