Profiles vs Permission Sets: The Access Model That Matters in 2026

If your Salesforce org has more than five Profiles that look nearly identical to each other, you have a common problem: Profile proliferation. It starts when one user needs slightly different access from another. The natural response is to clone the existing Profile and adjust it. Then someone else has a slightly different need. Another clone. Repeat until you have 15 Profiles, nobody can remember what makes them different, and every permission change needs to be applied to every single one.

The modern Salesforce access model solves this — but only if you understand how it works. This session covers Profiles vs Permission Sets, the additive rule, Permission Set Groups, and the migration path.

Profiles: the baseline requirement

Every Salesforce user must have exactly one Profile. No user can have zero Profiles; no user can have two. The Profile is the baseline — it defines the minimum access level that category of user has in your org.

Profiles control:

• Object-level permissions (read, create, edit, delete, view all, modify all)
• Field-level security (visible and editable per field)
• Page layout and record type assignments
• App access
• System permissions (API Enabled, Modify All Data, View All Data, etc.)
• Login hours and IP restrictions

In the traditional model, Profiles did everything. When users needed different access, you cloned the Profile and tweaked it. That was the only tool available, so it got overused.

Permission Sets: additive access

A Permission Set is a collection of permissions that can be assigned to users in addition to their Profile. A user can have multiple Permission Sets. Permission Sets add permissions on top of what the Profile grants.

The critical rule: Permission Sets are additive only. They can grant access the Profile doesn't grant. They cannot remove or restrict access the Profile already grants.

Permission Set Groups: bundling sets for clean management

Permission Set Groups let you bundle multiple Permission Sets and assign the bundle as a single unit. Instead of assigning 12 individual Permission Sets to every user in a particular role, you create one Permission Set Group containing all 12 and assign the Group.

Benefits:

• One assignment per user instead of many.
• Self-documenting: the Group is named for the access it represents ("Sales Rep Standard Access," "Finance Read-Only," etc.).
• Muting Permission Sets: you can suppress a specific permission within a Group's context without removing the underlying Permission Set entirely.
• Auditable: you can see at a glance exactly what access a role is supposed to have.

The minimum-Profile model

The recommended 2026 design pattern is:

1. One baseline Profile per genuine user category (e.g., Standard User, Read-Only User, System Administrator). Each Profile grants only the absolute minimum access every user in that category needs, regardless of role.
2. Permission Sets for specific capabilities above the baseline — field-level access to sensitive objects, elevated system permissions, app-specific access.
3. Permission Set Groups bundling the relevant Permission Sets for each business role (Sales Rep, Support Agent, Finance Analyst, etc.).
4. User Access Policies (where available) automatically assigning the right Permission Set Group when a user attribute changes — department assignment, role update, or custom field.

The result: when someone joins as a Sales Rep, they get the Standard User Profile plus the "Sales Rep" Permission Set Group. Everything they need is in the Group. If their role changes, you reassign the Group — one action.

Why Salesforce is moving in this direction

Salesforce has indicated — at Dreamforce, through product roadmap announcements, and through where new features are being built — that Permission Sets are the future of access management in the platform. Profile-first design is being actively de-emphasised:

• New access control features are being added to Permission Sets and Permission Set Groups, not Profiles.
• User Access Policies — automatic permission assignment — are a Permission Set feature only.
• Enhanced Permission Analysis tools are built around Permission Sets, not Profiles.

Building new orgs on a Profile-heavy model in 2026 is building on a foundation Salesforce is reducing investment in.

The known limitation: Record Types

Record type availability and the default record type assignment are still controlled through Profiles — not Permission Sets. This is a significant limitation for orgs that use Record Types extensively, and it complicates full migration to a minimal-Profile model.

Until Salesforce extends Permission Sets to cover Record Type assignment, some Profile complexity may need to remain. Plan for this when scoping a migration — don't assume you can reduce to a single baseline Profile if your org has complex Record Type requirements.

How to migrate a Profile-heavy org

1. Audit first. Run the Permission Set Analysis and look at Access Summary for representative users in each Profile. Document what each Profile grants that differs from a genuine baseline.
2. Define the baseline. Identify the minimum access every user in each category needs regardless of role. That becomes the baseline Profile.
3. Map the delta. Everything granted above the baseline becomes Permission Sets — grouped by logical access package (not by individual user quirks).
4. Build Permission Set Groups. Bundle the sets into Groups named for the business role.
5. Migrate one user type at a time. Switch a cohort to the new baseline Profile + Group. Verify with Access Summary before declaring success.

The compliance advantage

For orgs in regulated industries — financial services, healthcare, any org using Salesforce Shield — the Permission Set model makes compliance reporting significantly cleaner. When an auditor asks "who has access to this sensitive field?", a well-structured Permission Set model lets you answer specifically: which Group grants it, which users have that Group, and when they were assigned.

Twenty cloned Profiles with subtle differences is not an auditable answer. Named, documented Permission Set Groups are.