Salesforce Permission Sets Explained with Examples and Best Practices
Salesforce permission sets give users additional access without changing their profiles. A user has one profile and can receive multiple permission sets, either directly or through permission set groups. These permissions add to the access the user already has.
For a small Salesforce team, the goal is to give each user the access they need and confirm they have no more than that. This guide walks through creating and assigning a permission set, explains groups and muting, and shows how to troubleshoot access.
What permission sets do and how access adds up
A permission set is a collection of settings and permissions: object and field access, user permissions, app and tab visibility, Apex class and Visualforce page access, and more. You assign it to the users who need that access, on top of whatever their profile already allows.
Access is additive: permission sets can grant access, but they cannot take it away. Leaving a permission unchecked in one set does not remove access granted by a profile, another set or a permission set group. To remove access, find every source that grants the permission and adjust those grants or assignments. Review the effect on other users before changing a shared profile or set.
Salesforce recommends keeping profiles close to minimum access, then adding reusable permission sets and grouping them by persona, such as support agent or sales rep.
Profiles vs permission sets vs permission set groups
| Profile | Permission set | Permission set group | |
|---|---|---|---|
| Per user | Exactly one, required | Zero or more | Zero or more |
| Purpose | Baseline settings such as login hours, login IP ranges, page layout assignments and default record types | Adds specific access for a task or feature | Bundles several sets into one assignment for a persona |
| Can it remove access? | Removing a profile grant only removes access if no other source grants it | No | Muting suppresses grants within this group only |
| Typical example | A minimum access profile for all internal users | Support - Edit Cases | Support Agent, containing case, knowledge and reporting sets |
In practice, keep the profile lean and put access for specific features or tasks into permission sets. Use a group when several users need the same combination of sets.
The five permission set types and when to use each
Salesforce lists five permission set types. Permission set groups bundle sets together; they are covered separately below.
| Type | What it is | When to use it |
|---|---|---|
| Custom | Created by your admins for a task and reusable across roles | Most of your day-to-day access design |
| Standard | Prebuilt by Salesforce for a single feature and tied to a permission set license | When users need the standard access for that feature license |
| Managed | Installed with a managed package and carries the package namespace. Subscriber orgs can’t edit its permissions | Granting access to an installed app. Clone for an editable copy, or add a custom set for extra access |
| Integration | Provided by Salesforce for specific integrations. Only some permission types are editable, depending on the use case | Integration users and connected services |
| Session-based | Grants access only while it is activated for a particular session | Elevated or sensitive access that should switch on for a task rather than stay on all day |
Licenses and record access
A permission set works within the limits of the user’s licenses and Salesforce’s record access rules.
Licenses. A user needs a user license or permission set license that supports the permission you are granting. When you create a permission set, you can choose a license or select None. None lets you use the set across license types, but it does not bypass license requirements. Each user must be entitled to every included permission before you can assign the set.
Record access. Object permissions control actions such as reading or editing Cases. Field permissions control which fields a user can see or change. Sharing settings, such as organization-wide defaults, the role hierarchy and sharing rules, generally determine which individual records a user can access. If a user has Edit on Cases but can’t edit a particular case, check their sharing access to that record. Broad permissions such as View All Records or Modify All Records can override sharing settings for an object.
How to create and assign a permission set
The task: three support agents need to edit cases. A fourth agent, still in training, should keep read-only access. All four share the same profile.
Check existing access. Confirm all four agents have Read on Cases and that the trainee has no Edit access from a profile, permission set or group. If the shared profile already grants Edit, adding a permission set will not remove the trainee’s access. Review who relies on that profile before moving Edit into a permission set for the agents who need it.
Check licenses. Confirm each agent’s user license supports edit access to Cases.
Create the permission set. From Setup, enter Permission Sets in the Quick Find box and click New. Enter the label Support - Edit Cases and the API name Support_Edit_Cases. For this example, leave License set to None, confirm each assignee’s license supports the included permissions, then save.
Grant the minimum access. Open Object Settings, select Cases and click Edit. Enable Read and Edit. Leave Create, Delete, View All Records and Modify All Records unchecked unless the task requires them. Give Read access to the fields agents need to see and Edit access only to fields they need to update, such as Status and Priority. Save.
Assign it. Click Manage Assignments, then Add Assignments. Select the three agents and click Next. Choose an expiration date if the access is temporary, or select No expiration date, then click Assign.
Verify an agent’s access. Open one agent’s user record and view their User Access Summary (steps in the troubleshooting section below). Confirm Edit on Cases appears, granted by Support - Edit Cases. Then test that the agent can update Status or Priority on a case they can access.
Verify the trainee’s access. Repeat the check for the trainee. Confirm the trainee can read a case but cannot edit it. Edit on Cases should not appear in the summary. If it does, use Access Granted By to find the profile, set or group responsible.
Checking both users catches a profile or older permission set granting more access than you intended.
How groups and muting change effective permissions
A permission set group bundles several permission sets so you can assign them together to users with the same responsibilities. An assigned user receives their combined permissions, except those muted within the group.
A muting permission set suppresses selected permissions within one group without editing the sets it contains. Muting affects only its own group. A user keeps the permission if a profile, a separately assigned permission set or another group grants it.
Example. A Support Agent group contains Support - Edit Cases and a reporting set that grants Export Reports. You create a Contractor Support group with the same sets, then mute Export Reports within that group.
| Contractor’s access sources | Export Reports before muting | Export Reports after muting |
|---|---|---|
| Contractor group only | Yes | No |
| Contractor group plus a separately assigned reporting set | Yes | Yes, granted by the separate set |
| Contractor group plus a profile that grants Export Reports | Yes | Yes, granted by the profile |
After adding a muting permission set, open an affected user’s User Access Summary to confirm Export Reports is no longer granted. If it is still present, check Access Granted By for another source.
Assignment expiration and session activation
Both give temporary access, but they work in different ways.
| Assignment expiration | Session-based permission set | |
|---|---|---|
| What is temporary | The user’s assignment to a set or group | The access itself, per session |
| How it starts | Assign as usual and choose an expiration date | Assign the set, then activate it for a session through Flow (the Activate Session-Based Permission Set action) or the API (SessionPermSetActivation) |
| How it ends | Access from the assignment expires on the chosen date; the assignment remains listed | The session ends, or the permission set is explicitly deactivated |
| Best fit | A contractor who needs access for the length of a project | Access activated for an elevated task and limited to the current session |
Assigning a session-based permission set does not activate it. The user receives access only after activation for their current session. That access can continue after the activating flow finishes; deactivate it explicitly if it must end sooner. Session-based permission sets don’t support asynchronous processes.
How to troubleshoot unexpected or missing access
Start with the built-in User Access Summary. From Setup, enter Users in the Quick Find box, select Users, open the user’s record and click View Summary. Refresh the page so the data is current. You need the View Setup and Configuration permission to see it.
Unexpected access. Find the permission, open its row action and click Access Granted By. Review the profiles, permission sets and groups that grant it. Remove the user’s unnecessary assignments or change the grants, checking who else relies on a shared source before editing it.
Missing access. Confirm the permission appears in the summary. If it doesn’t, check that the assignment is active and unexpired, the user has the required licenses, and no group muting suppresses the permission. For a session-based set, also check activation. If the object permission is present but a specific record won’t open, check record sharing. If the record opens but a field can’t be edited, check field permissions.
For a wider review across many sets and groups, Salesforce’s optional User Access and Permissions Assistant app includes Permissions Analyzer. You can install it from AppExchange by following Salesforce’s installation guidance. For more fixes, see our guide to troubleshooting Salesforce permissions.
Best practices for managing permission sets
- Grant the least privilege. Give only what the task needs, as in the worked example: Read and Edit on Cases without Delete, View All Records or Modify All Records.
- Keep profiles minimal. Move feature access into permission sets, so you can manage task access through assignments. Check other sources before assuming that removing one assignment removes the permission.
- Use clear names. Name sets for the task, such as Support_Edit_Cases or Sales_Data_Read, and name groups for the persona.
- Assign by persona. Use a permission set group for users who need the same combination of access. Assign extra sets only for tasks outside that group.
- Review regularly. Remove project access when the project ends, and set expiration dates on temporary assignments. Remember that access granted by other sources still applies.
How a small team can review and deploy permission changes
Permission differences between a sandbox and production can leave users with unexpected access. A short, repeatable workflow helps a team of one to five people review changes and verify the result:
Build and test in a sandbox. Make the change and test both a user who needs the access and one who should not have it, as in the worked example.
Compare sandbox and production. Use the free Blue Canvas Profiles & Permissions tool to compare the permission set across orgs. Filter by object to review object and field-level differences.
Review the intended change. Review all differences, then select only the changes you intend to deploy. If you can, have a second person look.
Deploy. Add the reviewed items and deploy them to production. If deployment fails, review the error, fix the cause and retry. If you exclude an item, confirm that the remaining changes still meet the intended access requirements.
Check access afterward. Review the User Access Summary and repeat both user tests in production.
For tracking permission changes over time, see our post on Salesforce permission change management.
Want help setting up a process for reviewing and deploying permission changes for your org? Book a consultation with the Blue Canvas team.
Frequently asked questions
Can a permission set remove access a user already has? No. Permission sets only add access. To remove it, remove or change every source that grants it to the user. Muting works only within its group and only removes the user’s permission if no other source grants it.
Why can a user still see a field after I unchecked it in their permission set? Another source still grants it. Use Access Granted By in the User Access Summary to find the profile, set or group responsible.
Should I use assignment expiration or a session-based permission set for a contractor? Use assignment expiration when access should last for the length of a project. Use a session-based permission set when access should activate for a particular session. If access must end when a task finishes, plan explicit deactivation.
Can I edit a permission set that came from a managed package? No. Subscriber orgs can’t edit its permissions. Clone it to create an editable copy, or add a custom set for extra access. Adding a custom set will not restrict permissions granted by the managed set.
A user has Edit on an object but still can’t edit a record. Why? Edit on the object does not guarantee edit access to every record. Check the user’s sharing access to that record. If only a field is blocked, check field permissions; if saving fails, review the error for validation rules or a record lock.