Profile vs Permission Set vs Permission Set Group: The Complete Salesforce Access Guide

TL;DR

• The mnemonic that ends the argument: Roles see, Profiles do, Permission Sets add.
• Use the minimum-access Profile pattern: assign every user the same near-empty Profile, then layer Permission Sets and Permission Set Groups for actual capability.
• Permission Set Groups mute specific permissions for a role — a subset of users in a group can have a specific permission removed without rebuilding the group.
• Salesforce is moving away from Profiles for most permissions over the next several releases. Get ahead of it.

If "what's the difference between a Profile and a Permission Set?" still slows you down at architecture review, this article is for you. We'll establish a clean mental model in the first 30 seconds, then go deep on the patterns that actually matter for production orgs in 2026.

The mnemonic that ends the confusion

Three layers, three jobs.

• Roles see — the role hierarchy controls record visibility via owner-based access. A Role gives you the ability to see records owned by people below you on the hierarchy. It does not grant any capability.
• Profiles do — Profiles control core capabilities a user has: which apps they can use, which record types they can see, and the smallest reasonable defaults for object permissions. Every user must have exactly one Profile.
• Permission Sets add — Permission Sets layer additional capability on top of Profiles. They're additive only. A user can have many Permission Sets.

The most common misuse is treating Profiles like Permission Sets — building 30 different Profiles, each with subtly different permissions, for 30 different roles. That's a maintenance nightmare. Stop doing it.

The minimum-access Profile pattern

The pattern senior architects use in 2026:

1. One near-empty Profile for almost every user. The "Standard User" or a custom "Minimum Access" Profile. It grants login access, basic UI tabs, and very little else.
2. A Permission Set Group per role (e.g., "Sales Rep PSG", "Customer Support PSG", "Finance Analyst PSG"). The PSG bundles 5–15 individual Permission Sets that, together, grant the capabilities of that role.
3. Atomic Permission Sets that each grant a single capability (e.g., "Can edit Opportunities", "Can view Reports", "Can run Bulk API"). Atomic Permission Sets are reusable across multiple PSGs.

Result: changing what "Sales Rep" can do means editing one PSG, not editing 12 Profiles. New employee? Assign one PSG. Promotion? Swap PSGs.

Permission Set Groups: muting

The single most-underused feature.

A Permission Set Group can mute specific permissions. Imagine your "Customer Support PSG" includes "Can edit Cases", "Can edit Accounts", and 8 other capabilities. Now you onboard a junior support rep who should have everything except "Can delete Cases." Without muting, you'd build a separate "Junior Support PSG" with one less Permission Set.

With muting, you create a Mute Permission Set inside the same PSG that strips "Delete Cases" specifically for users in this PSG who are also assigned the Mute Permission Set. The PSG stays clean.

Customer Support PSG
├── Permission Set: Edit Cases
├── Permission Set: Edit Accounts
├── Permission Set: Run Reports
└── Mute Permission Set (Junior): -Delete Cases

Mute Permission Sets are surgical. Use them sparingly — 4–6 per org is plenty.

What goes where

A reference table for fast lookup.

Notice the asymmetry: a few things still only live on Profiles (default Record Type, default Page Layout, login hours, IP ranges). Salesforce is moving these to Permission Sets over time, but as of 2026 they remain Profile-only.

How they interact with the sharing model

Profiles and Permission Sets are capability gates. The sharing model — OWDs, Role Hierarchy, Sharing Rules, Manual Sharing, team sharing — is the visibility gate. Both must be satisfied for a user to interact with a record.

A Sales Rep with "Edit Opportunity" on their PSG (capability ✅) can still be unable to edit a specific Opportunity if they don't have access to that record (visibility ❌). The error message is the same — "You don't have access" — and admins burn hours debugging the wrong layer. Start by asking: is this a capability problem or a visibility problem?

Migration from old-school Profiles

If your org has 20 custom Profiles built up over years, here's the playbook.

1. Audit. Export Profile metadata. Diff each pair of Profiles. Document which permissions are common and which differ.
2. Define your roles. From HR and team structures, list the 5–15 functional roles in your org (Sales Rep, Sales Manager, Marketing Ops, etc.). These will become your PSGs.
3. Build atomic Permission Sets for capabilities that recur across roles. "View Reports", "Edit Opportunities", "Run Data Loader" — each its own Permission Set.
4. Build PSGs that compose atomic Permission Sets per role.
5. Migrate users in waves. Start with one team, switch them to the minimum-access Profile + their PSG. Keep their old Profile as fallback for 1 sprint. Check for surprises (login hours, default record types).
6. Retire old Profiles. Once everyone is on the new model, delete the old Profiles. Don't leave them around as zombies.

Plan 2–3 quarters for a 20-Profile org. The maintenance savings start in quarter 2.

Common mistakes

• Profile permissions edited "just for one user." Hundreds of orgs have a Profile called "Sales Rep — Marketing Special" because one rep needed an extra permission. Don't. Create a Permission Set.
• Forgetting to assign the PSG. Permission Set Groups must be explicitly assigned per user. They don't auto-flow from a Profile change.
• Mute Permission Sets sprawl. If you have 20 mute PS in one PSG, the PSG isn't right. Split it.
• Ignoring the Profile login restrictions. Login Hours and IP Ranges still live on Profiles. If your minimum-access Profile is too permissive, you've widened your attack surface even if your PSGs are tight.
• Treating "Permission Set Group" as a name-only thing. PSGs recompute effective permissions on assignment. They're not a UI shortcut; they're an evaluation.

Frequently asked questions

Are Profiles being deprecated? Salesforce is signaling that most permissions will move off Profiles to Permission Sets over the next several releases. Profiles aren't going away entirely — login hours, IP ranges, and a few defaults will remain Profile-only — but the era of building 30 custom Profiles is over.

Can a user have zero Permission Sets? Yes. They get only what their Profile grants. With the minimum-access Profile pattern, that means almost nothing — login + a couple of tabs.

What's the difference between a Permission Set and a Permission Set Group? A Permission Set is one bundle of permissions. A PSG is a collection of Permission Sets, plus optional Mute Permission Sets, treated as one assignable unit. Use PSGs when you have a recurring "role" pattern.

How do I see what permissions a user effectively has? Setup → Users → click the user → "View All Permissions." It shows the union of Profile + assigned Permission Sets + PSG-derived permissions, minus any muted ones.

Does this affect Agentforce agents? Yes. An agent runs as the calling user. The agent's effective permissions = the user's effective permissions. Tightening Profiles tightens what your agents can do, too.

What to read next

• Profile, Permission Set, Permission Set Group — the dictionary entries.
• Field-Level Security, Role Hierarchy, Sharing Rules — the visibility-side companions.
• Salesforce Sharing & Visibility — the Complete Guide — the deeper dive on the sharing model (when it ships).

If you only do one thing: pick a low-risk team, build their first PSG this week, and migrate them off their custom Profile. The pattern only clicks once you've used it.