Permission Sets vs Permission Set Groups vs Profiles in 2026: Where Each Kind of Access Belongs

TL;DR

• Profiles are staying, permissions and all. Salesforce cancelled the plan to remove permissions from profiles. It still recommends a permission set led model, and so do we.
• The profile holds defaults and restrictions: default app, default record type, page layout assignment, login hours, login IP ranges, password policy and session settings. Nothing else has a home for those.
• Permission sets hold capabilities. Keep them small and name them for what they allow.
• Permission set groups hold roles. Bundle the capability sets a job needs, and assign the group.
• Access only adds up. If any profile, set or group grants a permission, the user has it. A mute removes a permission only inside its own group.
• Record visibility is not a permission. "She can't see the Auckland accounts" is a sharing question, and no permission set should be the answer.

What You'll Learn

• What each of the three is for in 2026, now the retirement is off
• A quick way to decide where any access request belongs
• How Salesforce works out a user's effective access, and why muting surprises people
• How to design capability sets and role groups that stay manageable
• The limits, expiry dates and automation that change the design
• What changed in 2026: profile filtering, access summaries and the dates people get wrong

The Problem

Most of what ranks for "permission sets vs profiles" still tells you profile permissions are being retired in Spring '26. They are not. Salesforce stopped enforcing that date in a community post in November 2023, and published a Help article in June 2026 confirming the cancellation, "based on customer feedback and remaining feature gaps". Profiles "will continue to support permissions for now".

So admins are left with three tools that can all grant access, and no deadline forcing a choice. The result in a lot of orgs is the worst mix: some grants on profiles, some in permission sets, a few groups nobody remembers building, and a mute that was supposed to take something away and didn't.

Comparing the three in the abstract does not help much. Asking where a particular piece of access belongs does, and that question has a clear answer for almost every request.

Common questions this article answers:

• Should I still move permissions off profiles if the retirement is cancelled?
• When do I need a permission set group instead of a few permission sets?
• I muted a permission in a group. Why does the user still have it?

Quick Answer

Sort the request before you build anything.

The same sorting as an interactive picker:

What Each One Is For

A profile is the one thing every user must have, and only one of. In a permission set led model it is a thin baseline. Salesforce's own advice is to give users "the Minimum Access - Salesforce profile, or a clone of it" when possible, and add everything else through permission sets and permission set groups. Minimum Access grants almost nothing: a handful of permissions such as Access Activities and Chatter Internal User.

A permission set grants a capability. Help lists what it can carry: object permissions, field permissions, user permissions, custom permissions, tab settings, Apex class access, Visualforce page access, connected app access, and record types and apps (but not the defaults for either). A user can have many.

A permission set group bundles permission sets. Salesforce "calculates the combined permissions from the included permission sets", and the user gets the result through one assignment. Groups have been available in all editions since Spring '24, so edition is no longer a reason to skip them.

The split that works: the profile sets defaults and restrictions, permission sets hold capabilities, groups describe roles.

What Still Lives Only on a Profile

Salesforce's cancellation article names the settings that keep profiles necessary: default assigned apps, default record types and page layouts, login hours, login IP ranges, password policies and session settings. Permission sets can grant access to an app or a record type, but cannot make either the default, and they cannot assign page layouts at all.

That list is why most orgs still need more than one profile. If two teams need different page layouts or different login hours, they need different profiles. Clone Minimum Access - Salesforce for each, change only the defaults and restrictions, and put no grants on them. We covered why the cancellation does not change the case for this in Salesforce cancelled the profile permissions retirement.

How Access Adds Up

Salesforce's Help states the rule directly: profiles, permission sets and permission set groups grant access "but not to deny access". A user's effective access is everything granted by their profile, every group and every directly assigned set, added together. To revoke a permission, "you must remove all instances of the permission from the user".

Muting is the only subtraction, and it is narrow. A group can have one muting permission set, and it removes permissions from that group's combined result. Salesforce is explicit about the limit: if the user gets the same permission "via a profile, permission set, or different permission set group, the user still has these permissions despite the muting permission set."

That is how a mute fails in practice. Walk through both cases for one support agent:

The fix is always the same: find every source of the permission for that user and remove the ones that should not be there. The User Access Summary on a user's record shows which assignments grant what. From September 2026, orgs with Agentforce in Setup can also ask for a plain-language summary of a profile, set or group, and group summaries "show the net effect of any muting permission set". That shows the group, not the user, so the direct assignment in the example above would still not appear in it.

Designing Sets and Groups That Stay Manageable

Build capability sets, not people sets. A permission set called Case_Work or Export_Reports can be reviewed: anyone can read the name and guess what it grants. A set called Sarah_Extra_Access cannot, and it outlives Sarah's job.

One group per role. Support_Agent, Support_Lead, Finance_Approver. A user normally gets one role group plus, occasionally, a capability set for something specific to them. If the same capability set keeps being assigned to everyone in a role, move it into that role's group.

Reach for a mute only when a role is a near copy of another. A Support_Contractor group that reuses the agent sets and mutes Delete on Case and Export Reports is cleaner than a parallel set of permission sets that drift apart. If you find yourself muting half a group, build a different group.

Put an expiry date on anything temporary. Permission set and group assignments can carry an expiration date once you turn the feature on in User Management Settings. The assignment ends at 11:59 PM on that date in the time zone you choose. Sets and groups that include Manage Users, Assign Permission Sets or Manage Profiles and Permission Sets cannot be given an expiry date. That is deliberate: those are the grants an access review should look at by hand.

Automate assignment where you can. User Access Policies, generally available since Summer '24 in Enterprise and Unlimited editions, assign permission sets, groups, permission set licences, package licences, queues and public groups when a user is created or updated and matches the policy's criteria. A policy that gives everyone in the Support department the Support_Agent group removes a manual step that tends to get done differently each time.

Know the limits before you design to them. Salesforce's Enterprise Edition limits page lists 1,000 custom permission sets per org (1,500 counting managed package sets), 800 custom permission set groups (1,000 with managed packages), and 1,500 custom profiles per user licence type. A group can hold up to 100 permission sets. Older limit sheets that say 1,500 created permission sets are out of date. Most orgs never reach these numbers, but a "one set per person" design can.

Watch the group's status. After you change a set inside a group, Salesforce recalculates the group. While it shows Outdated or Updating, users keep the permissions from the last completed calculation, and you cannot change who is assigned. Changes to standard permission sets are recalculated daily. If a change is not showing up, check the status and use Recalculate before you start debugging anything else.

Not Everything Is a Permission

A lot of access requests that reach the admin are about records, not objects. "He can't see the Wellington opportunities." "She needs to edit cases from the escalations team." The object permission is usually already there. What is missing is sharing.

Salesforce applies two separate checks: whether you can do something to an object at all (permissions), and which records of that object you can reach (org-wide defaults, the role hierarchy, sharing rules, teams and manual sharing). Granting View All or Modify All on the object fixes the symptom by skipping the second check entirely, for every record. That is how least-privilege designs turn into "everyone can see everything".

If the picker sends you to sharing, check the org-wide default for the object first, then whether a sharing rule or team covers the case. If an error message is what brought you here, INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY walks through the related-record version of the same question.

What Changed in 2026

• The retirement is formally off. Help article 003834041, published June 2026, confirms it, and recommends a permission set led model anyway.
• Profile filtering is enforced in Winter '27. Users without View All Profiles (or one of the other bypass permissions) see only their own profile name. Anything that reads another user's profile name in user context can change behaviour. We cover testing for it in Winter '27 turns on profile filtering. This is one more reason to stop encoding access decisions in profile names.
• Agentforce access summaries. Since September 2026, orgs with Agentforce in Setup (Enterprise, Performance, Unlimited and Developer, with Foundations or Agentforce 1) can generate summaries of profiles, sets and groups.

If Your Org Is Half Migrated

Most orgs are. Pick a rule and write it down: new grants go into permission sets, existing profile grants move when someone touches them. That stops the profile side growing without a big-bang project.

When you do move a profile's grants, the order that causes the fewest surprises is: build the capability sets, build the role group from them, assign the group alongside the current profile, then switch the user to a thin profile clone. Because access only adds up, a user who has both the old profile and the new group has the union of the two, so nothing breaks while you check. Remove the old grants only after the user's access summary shows the group covers what they use.

For deploying the result through a pipeline, deployable permission sets for a delivery team has the XML and the CI user setup. Permission sets also conflict far less in git than profiles do, which resolving merge conflicts in Salesforce metadata explains from the admin side.

Frequently Asked Questions

Q: Is there a new date for removing permissions from profiles?

No. The Help article says profiles "will continue to support permissions for now" and gives no replacement date. Anyone quoting a new release for it is adding something the source does not say.

Q: Do I need permission set groups if I already use permission sets?

Not always. If most users need only one or two sets, direct assignment is fine. Groups earn their place once a role needs four or five sets: one assignment instead of five, one place to change the role, and the option to mute for a near-copy role.

Q: I muted a permission but the user still has it. Is muting broken?

Muting works only inside its own group. If the user also gets the permission from their profile, a directly assigned set or another group, they keep it. Open their User Access Summary to find the other source.

Q: Can permission sets set a user's default record type or page layout?

No. Permission sets can grant access to record types and apps, but not make them the default, and page layout assignment is profile only. That is the main reason orgs still need several thin profiles.

Q: Should every user be on Minimum Access - Salesforce?

As the base, yes, or a clone of it where a team needs different defaults or login restrictions. Integration users are worth treating separately: give them only the API access the integration actually uses.

Key Takeaways

• Profiles are staying, but the advice has not changed: grants belong in permission sets.
• The profile keeps defaults and restrictions, and nothing else needs to live there.
• Capability sets, role groups and the occasional mute cover almost every request.
• Access is a union. A mute only subtracts inside its own group, so check every source.
• Temporary access should expire on its own, and routine assignment can be automated.
• If the request is about which records someone can see, fix sharing, not permissions.

What's Next?

• Salesforce cancelled the profile permissions retirement. Migrate anyway.
• Winter '27 turns on profile filtering
• Deployable permission sets for a delivery team
• What developers need instead of Modify All Data

Resources & References

• Permissions in Profiles Retirement Cancelled (Salesforce Help, 003834041)
• User Permissions and Access (Salesforce Help)
• Standard Profiles (Salesforce Help)
• Permission Set Group Status and Recalculation (Salesforce Help)
• Muting Permissions in Permission Set Groups (Salesforce Help)
• Assign Permission Sets and Groups with Expiration Dates (Salesforce Help)
• User Access Policies (Salesforce Help)
• Enterprise Edition Limits (Salesforce Help)
• Winter '27 Permissions Release Notes (Salesforce Help)
• Mute Permissions in Permission Set Groups (Trailhead)