Permission Sets & Permission Set Groups: The Modern Way to Manage Access
How Salesforce grants access today — what permission sets and permission set groups do, how their permissions combine, and why the platform is steering you away from profiles.
Permission sets are how modern Salesforce orgs hand out access. Where the profile once carried almost everything a user could see and do, today the recommended approach is lean: the profile sets a baseline, and permission sets and permission set groups layer on the rest. This shift — often called the permission set-led security model — is the single biggest change in how admins think about user access, and it shows up across nearly every Salesforce certification.
This guide walks through what each tool does, how a permission set group calculates its combined permissions, the often-misunderstood muting feature, assignment expiration, and how to automate the whole thing with User Access Policies. Everything here is verified against current Salesforce documentation for the Summer ’26 release.
What Permission Sets Are and Why They Matter
A permission set is a collection of settings and permissions you assign to users to grant access beyond what their profile already gives them. That can include object permissions, field-level security, app and tab visibility, Apex class and Visualforce page access, system permissions like “Manage Users,” and custom permissions.
The reason permission sets matter so much is additive flexibility. A user has exactly one profile, but can hold many permission sets. So instead of building a sprawling profile for every slight variation of a role, you grant a minimal baseline through the profile and stack targeted, reusable permission sets on top. Need to let three sales reps convert leads? Create a “Lead Conversion” permission set and assign it to those three — no new profile required.
Permissions in Salesforce are additive and there is no “deny.” If any profile or permission set assigned to a user grants a permission, the user has it. The only way to take a granted permission back inside a group is muting, covered below.
Profiles vs. the Permission Set-Led Model
For years, profiles did the heavy lifting. Over the past several releases, Salesforce has moved to a model where the profile provides baseline settings and permission sets and permission set groups handle the bulk of user access. This is the model Salesforce now recommends for new and existing orgs alike.
You may have heard that “permissions on profiles are being retired in Spring ’26.” That announcement was real, but the enforcement was postponed. As of the latest Salesforce guidance, profiles continue to support permissions, and there is no hard cut-off date. What has not changed is the direction of travel: Salesforce is investing in permission sets, permission set groups, and the surrounding tooling, not in profiles.
Do not plan around a fixed “profile permissions end-of-life” date — the Spring ’26 enforcement was postponed and no replacement date has been set. Treat the migration to a permission set-led model as a strongly recommended best practice you can phase in, not a forced deadline.
Profile
Baseline- Exactly one per user — mandatory
- Defines default settings and a permission floor
- Still owns login hours, IP ranges, default apps, default record types, and page layout assignment
- Hard to scale: a tweak for one role often spawns a new profile
Permission Sets & Groups
Recommended- Many per user — fully additive
- Grant access aligned to tasks or job functions
- Reusable across roles, so one change updates everyone assigned
- Where Salesforce focuses new investment
What Stays on the Profile
Even in a fully permission set-led org, the profile does not disappear. Every user must still have one, and a handful of settings live on it because they have no permission set equivalent. The most important to remember:
- Default record types for objects
- Page layout assignment — Salesforce has stated the future here is Dynamic Forms, so this is not moving to permission sets
- Login hours and login IP ranges
- Default apps and basic user settings
Everything else — object and field access, system and user permissions, app/tab settings, Apex and Visualforce access — can and, under the recommended model, should be granted through permission sets.
Permission Set Groups Explained
Once you commit to permission sets, you quickly hit a new problem: a single user might need ten of them, and a team of fifty users multiplies that into hundreds of individual assignments. Permission set groups, introduced in Spring ’20, solve this. A group bundles multiple permission sets under one name and description, and you assign the group instead of each set.
The mental model is job function. A “Sales Manager” group might contain permission sets for lead conversion, forecasting, report folder access, and a custom commissions app. Assign that one group to every sales manager. When a new permission becomes necessary, you add a permission set to the group once and everyone assigned inherits it — no per-user rework.
| Object | Connects | Purpose |
|---|---|---|
PermissionSetAssignment | User ↔ permission set / group | Records which users are assigned a permission set or permission set group |
PermissionSetGroupComponent | Group ↔ permission set | Records which permission sets belong to a permission set group |
Favor many small, single-purpose permission sets over a few large ones. Granular sets are far easier to recombine into different groups for different roles — and easier to audit when someone asks “why does this user have that access?”
How Group Permissions Are Calculated
A permission set group calculates the combined permissions of every permission set it contains. The result is the union of everything inside — the most permissive outcome. If one set grants read access to Accounts and another grants edit, the group grants edit.
Because that union has to be computed, a group carries a recalculation status. Whenever you add, remove, or edit a permission set in the group, Salesforce recalculates the aggregated permissions. The process is not instantaneous: while it runs, assigned users keep the permissions from the last completed calculation. If the status reports a failure — which can happen after deployments or package updates — you can trigger a manual recalculation with the Recalculate button on the group’s detail page.
Two facts trip people up. First, group permissions are the most permissive union of the contained sets — there is no averaging or “lowest wins.” Second, recalculation is asynchronous; until it completes, users retain the previously calculated permissions. Expect scenario questions that hinge on both.
Muting Permission Sets
Muting is the one place where Salesforce lets you remove a permission rather than add one — and it only exists inside a permission set group. A muting permission set disables specific permissions that the group’s other permission sets would otherwise grant. Crucially, it does this without touching the underlying permission sets, so the same permission set can stay fully permissive in another group.
The killer use case is managed packages. When you install an app, its managed permission sets receive automatic updates from the vendor. If you clone one to strip out a permission you do not want, that clone stops receiving updates and can silently fall behind after an upgrade. Muting avoids the trap: keep the managed permission set as-is, accept the updates, and mute the single permission you are not ready to adopt.
Building a group with muting looks like this:
- From Setup, enter
Permission Set Groupsin Quick Find, select it, click New Permission Set Group, give it a label, and save. - Open the group, click Permission Sets in Group, then Add Permission Set, and add the sets the role needs (including any managed ones).
- Click Muting Permission Set in Group. Salesforce creates a muting set tied only to this group.
- In the muting set, find the object, field, or system permissions to remove and mute them, then save.
- Wait for the group’s status to show the calculation completed, then assign the group from Manage Assignments.
Watch for muting dependencies. Some permissions depend on others, so muting one can quietly break access that users legitimately need. Review the group’s combined permissions after muting before you assign it broadly.
Assigning Permission Sets & Expiration
You assign permission sets and groups from the Manage Assignments button on the record, from the user’s detail page, or in bulk through tooling. The newer capability worth knowing is time-boxed access: assignment expiration.
After enabling Permission Set and Permission Set Group Assignments with Expiration Dates in User Management Settings, you can attach an expiration date to an assignment. The user keeps the combined permissions right up to that date, then the assignment is removed automatically — no reminder, no manual cleanup. This is ideal for temporary elevated access: a contractor’s project window, a quarter-end close, or a one-week coverage stint.
Expiration applies to the assignment, not the permission set itself. When the date passes, the link between the user and the set or group is dropped; the permission set continues to exist for everyone else.
Automating Access with User Access Policies
Manually assigning permission sets every time someone joins, moves teams, or leaves does not scale — and it is where access drift creeps in. User Access Policies, which reached general availability in 2024, are Salesforce’s built-in automation for exactly this. A policy targets users by criteria (such as profile or other user fields) and then grants or revokes access in a single operation.
One policy can assign or remove permission sets, permission set groups, permission set licenses, and package licenses, and add or remove users from public groups and queues. Because it is declarative and purpose-built, it often replaces the record-triggered flows admins used to write for onboarding and offboarding.
- From Setup, enter
User Management Settingsin Quick Find and turn on User Access Policies. - Enter
User Access Policiesin Quick Find and create a new policy. - Define the user criteria (for example, profile equals “Sales User”).
- Add actions to Grant or Revoke the relevant permission sets, groups, or licenses.
- Run the policy manually for existing users, or set it active so it applies automatically as users match the criteria.
Pair grant and revoke policies. A grant policy gives joiners the right access on day one; a matching revoke policy strips it when someone changes role or leaves — the cleanest way to keep least privilege intact over time.
Best Practices for a Lean Model
Whether you are auditing an existing org or building fresh, the same principles apply. Operate on the principle of least privilege: grant the lowest access that still lets people do their jobs. Keep profiles thin and reserved for baseline settings. Build small, descriptively named permission sets and compose them into groups by job function. Use muting instead of cloning managed permission sets. And automate assignment and removal with User Access Policies so access tracks reality instead of decaying.
If you want to see how these access concepts connect to the wider platform, our walkthrough of the Salesforce security model shows where object-level security, record access, and field-level security fit around permission sets. And if you are mapping this to a certification path, you can browse all Salesforce certifications to find where access management shows up on your exam.
10 High-Yield Exam Facts
These distinctions about permission sets and groups appear across the Administrator, Advanced Administrator, App Builder, and Developer tracks.
- One profile, many permission sets — every user must have exactly one profile, but can hold any number of permission sets and groups.
- Permissions are additive, never subtractive — there is no “deny” except muting inside a group.
- Profiles still exist — the Spring ’26 retirement of permissions on profiles was postponed; no hard end date is set.
- Profile-only settings — login hours, login IP ranges, default apps, default record types, and page layout assignment stay on the profile.
- Groups aggregate — a permission set group grants the most permissive union of its member sets.
- Recalculation is async — until it completes, users keep the last calculated permissions; use Recalculate if the status is Failed.
- Muting only lives in groups — it removes a permission without cloning the underlying set, ideal for managed packages.
- Assignment expiration — enabled in
User Management Settings; the assignment is auto-removed on the date, not the permission set. - User Access Policies — automate granting/revoking permission sets, groups, licenses, public groups, and queues by criteria.
- Junction objects —
PermissionSetAssignmentlinks users;PermissionSetGroupComponentlinks sets to a group.
Test your access-model knowledge
Permission sets, groups, and muting are scenario-question favorites. Practice the exact distinctions Salesforce tests.
Frequently Asked Questions
No. Profiles are not being removed, and every user must still have exactly one profile. Salesforce previously announced retiring permissions on profiles in Spring ’26, but that enforcement was postponed. Profiles still support permissions today, while Salesforce recommends moving most access to permission sets and permission set groups.
A permission set is a single bundle of permissions you assign to grant access beyond the profile. A permission set group bundles several permission sets together so you can assign one package that matches a job function, rather than assigning each permission set individually.
A permission set group aggregates the combined permissions of all the permission sets it contains, so the result is the most permissive union of everything inside it. A muting permission set can then remove specific permissions from that combined result.
A muting permission set disables specific permissions that are otherwise granted by the permission sets inside a group. It lets you remove an object, field, or system permission for that group without cloning or editing the underlying permission sets, which is especially useful for managed package permission sets.
Yes. After enabling Permission Set and Permission Set Group Assignments with Expiration Dates in User Management Settings, you can set an expiration date on an assignment. The user keeps the combined permissions until that date, then the assignment is removed automatically.
User Access Policies automate granting or revoking access based on criteria such as a user’s profile or other fields. A single policy can assign or remove permission sets, permission set groups, permission set licenses, package licenses, public groups, and queues, which is ideal for onboarding, role changes, and offboarding.
All behavior verified against the official Salesforce Help, Trailhead, and Salesforce Admins documentation for the Summer ’26 release. For deeper reading, see the Salesforce Help articles on permission set group status and recalculation, the Salesforce Admins guide to profiles and permissions, and the Permission Set Groups Trailhead module.
Study smarter at CertifySF.com.