A permission set in Salesforce is a reusable collection of permissions and settings that grants users additive access on top of their profile — it can only grant access, never revoke it. The modern best practice is "profiles minimal, permission sets for everything": keep profiles lean (login hours, IP ranges, default record types, page-layout assignment) and use permission sets and permission set groups to hand out almost every other privilege. This keeps access reusable, auditable, and far easier to scale than cloning dozens of profiles.
Key takeaways
- A permission set grants additive permissions on top of a profile — it can grant access but never take it away.
- Create one in Setup → quick-find "Permission Sets" → New, add object, field, Apex, tab, and custom permissions, then assign it to users.
- Permission set groups bundle several permission sets by job role; muting permission sets remove specific permissions inside a group.
- Salesforce is steering admins toward minimal "least-privilege" profiles + permission sets/groups and is de-emphasizing permissions on profiles (no firm removal date — see below).
- Assign at scale with expiration-dated assignments, Flow, or the API/Data Loader.
What is a permission set in Salesforce?
A permission set is a bundle of settings — app and system permissions, object permissions (CRUD), field-level security (FLS), Apex class and Visualforce page access, custom permissions, tab visibility, and assigned record types — that you grant to one or more users regardless of their profile.
The defining rule: permission sets are purely additive. They can grant access, but they can never remove or revoke something a user already has through their profile or another permission set. To take access away you must remove a permission set or use a muting permission set inside a group (covered below). A single user can hold a profile plus many permission sets, so you can layer narrow capabilities onto exactly the people who need them.
Profile vs permission set vs permission set group
These three tools all control access, but they play different roles. Use this table to decide where a given setting belongs.
| Tool | One per user? | Additive? | Recommended use |
|---|---|---|---|
| Profile | Yes — exactly one | No (baseline) | Login hours, IP ranges, default record type, page-layout assignment, password policies |
| Permission set | No — many | Yes | Grant extra app/object/field/Apex/tab access to specific users |
| Permission set group | No — many | Yes (bundles sets) | Bundle permission sets by job role; use muting to fine-tune |
A profile is the mandatory baseline every user must have. Permission sets and permission set groups are the flexible, reusable layers you add on top.
How do I create a permission set in Salesforce?
- Go to Setup, use the quick-find box to search for "Permission Sets", and open it.
- Click New.
- Enter a Label (the API name auto-fills) and an optional Description.
- Optionally choose a License. Leave it as --None-- so the set can be assigned to users on any license; pick a specific license only if it must be restricted to that license type.
- Click Save.
Now open the saved permission set and add the access it should grant:
- App & System Permissions — toggle high-level capabilities (e.g. "Manage Cases", "Run Reports").
- Object Settings — set CRUD per object and configure field-level security so each field is visible or editable.
- Apex Class Access and Visualforce Page Access — enable specific custom code.
- Custom Permissions — gate access to your own features and flows.
- Tab Settings — set tabs to Default On / Available, which controls what users see alongside their custom list views.
- Assigned Record Types — make additional record types available.
Save your changes on each section. The permission set does nothing until you assign it.
How do I assign a permission set to users?
From the permission set detail page, click Manage Assignments → Add Assignment, select the users, and click Assign. You can also start from a user record (Setup → Users → [user] → Permission Set Assignments → Edit Assignments).
For more than a handful of users, assign in bulk:
- Expiration-dated assignments — set an end date so temporary access (contractors, seasonal staff) removes itself automatically.
- Flow — create PermissionSetAssignment records in an autolaunched or record-triggered flow to assign access based on a user's role, department, or onboarding stage.
- API / Data Loader — insert rows into the PermissionSetAssignment object to assign thousands of users at once.
What are permission set groups and muting permission sets?
A permission set group bundles several permission sets into one assignable unit, usually mapped to a job role. Instead of assigning a sales rep five separate permission sets, you build a "Sales Rep" group containing them and assign that one group. The user receives the combined (still additive) permissions of every set in the group.
Create one in Setup → quick-find "Permission Set Groups" → New Permission Set Group, add your component permission sets, and assign the group to users exactly like a permission set.
A muting permission set is a special component inside a group that removes specific permissions the group would otherwise grant. This is the one place you can subtract: keep a broad reusable permission set intact, but mute the one or two permissions a particular role shouldn't have — no need to clone or fork the original set.
Are Salesforce profiles going away in 2026?
Not exactly — and it is worth being precise here. Salesforce has been de-emphasizing permissions on profiles and publicly encouraging admins to manage access through permission sets and permission set groups instead. An earlier announcement signalled that some profile permissions would stop being maintained (a timeline around Spring '26 was floated), but that hard end-of-life was rolled back / de-emphasized, and Salesforce has not committed to a firm removal date.
Practical guidance: treat profile permissions as the legacy path and build all new access with permission sets. Profiles aren't disappearing — they still own login hours, IP ranges, default record types, page-layout assignment, and password policies — so you'll keep using them as the lean baseline. For a deeper look at structuring an org this way, see our Salesforce customization best practices.
Why use permission sets instead of more profiles?
- Reusable — one permission set covers a capability for many roles; no duplicate profiles.
- Scalable — layer narrow sets onto exactly the right users instead of maintaining a combinatorial explosion of profiles.
- Easier to audit — you can see precisely which set grants a sensitive permission and to whom.
- Cleaner deployments — package and move permission sets between orgs as part of your managed or unmanaged package strategy.
Need a hand designing a least-privilege access model or untangling a profile-heavy org? Our Salesforce consulting team has done it across 50+ projects since 2014.
Frequently Asked Questions
Can a permission set remove or revoke access?
No. Permission sets are strictly additive — they only grant access. To take a permission away, remove the permission set from the user, or use a muting permission set inside a permission set group to subtract specific permissions there.
How many permission sets can a user have?
A user can hold their one profile plus many permission sets and permission set groups simultaneously, and the combined access is additive. Per-org maximums for how many permission sets you can create depend on your Salesforce edition and features (managed-package sets count separately), so check current edition limits for exact numbers.
What is the difference between a permission set and a permission set group?
A permission set is a single bundle of permissions. A permission set group bundles multiple permission sets into one assignable unit — typically per job role — and supports muting to remove specific permissions within the group.
Can I assign a permission set to expire automatically?
Yes. When you create an assignment you can set an expiration date, after which Salesforce removes the assignment automatically. This is ideal for contractors, temporary projects, or seasonal access.
Do I still need profiles in Salesforce?
Yes. Every user must have exactly one profile, and profiles still control login hours, IP ranges, default record types, page-layout assignment, and password policies. The modern pattern is a minimal, least-privilege profile with permission sets layered on top.
How do I assign permission sets to many users at once?
Use a Flow to create PermissionSetAssignment records based on user attributes, or insert PermissionSetAssignment rows via the API or Data Loader for bulk assignment. Both scale far better than manual Manage Assignments for large user bases.