Permission Sets vs Profiles Salesforce: A Practical Migration Guide
Last Updated: March 10, 2026
Salesforce has announced a landmark shift in data access and user permission management: the company is sunsetting permissions on profiles, moving all granular access control to permission sets. Understanding the difference between Permission Sets vs Profiles Salesforce is no longer optional for admins: it is essential for compliance with the Spring ’26 end-of-life (EOL) deadline. Always verify current timelines in Salesforce official release communications.
This article explains exactly what is changing, what administrators should do right now, and how to plan a safe, phased migration from profile-based access in Salesforce to a modern permission set architecture.
Quick Answer
- Salesforce is sunsetting permissions on profiles. The Spring ’26 release is the announced EOL.
- Profiles will still exist but will only carry login hours, IP ranges, default apps/record types, and page layout assignments.
- All object, field, system, and app permissions move to permission sets and permission set groups.
- Admins should start auditing profiles and building a migration plan now. Do not wait for Spring ’26.
- Experience Cloud admins face additional complexity around external users, guest access, and FLS, see the Experience Cloud section below.
What Exactly is Happening and Why?
For the past three years, Salesforce has been signalling a decisive move away from profile-based permission management. The Spring ’26 release marks the end of permissions on profiles: object-level, field-level, system, and app permissions will no longer be configurable on a profile. Instead, they will only be available through permission sets.
The reasons behind this decision are architectural. Profiles were designed as an all-in-one bundle: a user’s identity, their UI defaults, and their data access entitlements were all packed into one object. As orgs grew in complexity (more user types, more integrations, more nuanced data access requirements) maintaining dozens of bloated profiles became unmanageable. Admins found themselves creating near-duplicate profiles just to add a single permission to a subset of users, creating drift, audit risk, and maintenance overhead.
Permission sets solve this by decoupling access from identity. A user has one lean profile (for defaults and login settings) and one or more permission sets that grant exactly the access they need. Permission set groups then bundle related permission sets into role-based packages that are easy to assign, modify, and audit.
The practical benefits of this model include: fewer objects to maintain, more granular and auditable access control, easier rollouts when applications update, and a much cleaner path to least-privilege security. These are the drivers behind Salesforce’s Salesforce user management changes and the shift to permission set-based access.
What Stays on a Profile vs What Moves to Permission Sets:
The table below summarises the division of responsibilities after the Spring ’26 changes take effect.
| Remains on Profile | Moves to Permission Sets Only |
|---|---|
| Login hours | User permissions (system & app) |
| Login IP ranges | Object permissions (CRUD) |
| Default app assignment | Field-level security (FLS) |
| Default record type assignment | Tab visibility |
| Page layout assignment (no investment planned here, future is App Builder / Dynamic Forms) | Record type access (non-default) |
| App access (non-default) | |
| Connected app access | |
| Apex class access | |
| Visualforce page access | |
| Custom permissions |
What this means in practice: every profile in your org should eventually be stripped down to a minimal baseline that only covers the items in the left column. Everything else should live in purpose-built permission sets, ideally grouped into permission set groups aligned to user personas or job functions (e.g. Sales Rep, Support Agent, Partner User, Community Member).
Salesforce Experience Cloud: The Tool for Digital Transformation in 2025
Important notes to keep in mind now!
There are several active features and beta capabilities that admins should be aware of as they begin preparing for this change:
User Access Policies (UAP)
This feature is designed specifically to help you migrate from profiles to permission sets at scale. It allows you to define criteria (e.g., by profile, role, or user attribute) and automatically assign permission sets based on those rules without manual user-by-user assignments. Check the Salesforce release notes for the current availability status of User Access Policies in your edition. This is the recommended path for large orgs managing hundreds or thousands of users.
Field-Level Security (FLS) on Permission Sets
Salesforce has introduced the ability to set field-level security permission sets (FLS) directly (rather than via profiles). Activate this in User Management Settings. This is a critical step for any org that relies heavily on FLS to protect sensitive fields. You will want to audit and replicate your profile-level FLS into permission sets before the EOL takes effect.
Early Opt-In to Disable Profile Permissions
Salesforce planned to provide the ability to voluntarily disable permissions on profiles ahead of the official EOL (announced for Spring ’24 release). This is a useful sandbox exercise: enabling it lets you test whether your permission set coverage is complete before the forced migration.
What to Check Right Now
- Run a permissions audit: export all profile permissions and compare with existing permission sets to identify gaps.
- Identify your highest-complexity profiles (most permissions, most users). These are your migration priority.
- Check if User Access Policies are available in your org edition and plan how to use them for bulk assignment.
- Review field-level security on profiles and prepare equivalent FLS permission sets.
- Flag any guest user or Experience Cloud profiles. These require special handling (see Experience Cloud section).
Migration Plan: Step-by-Step Checklist
The following checklist provides a structured approach for admins migrating from profile-based access to a permission set architecture. Work through each step in a sandbox before touching production.
Step 1: Audit All Profiles and Current Permissions
- Export all profile permissions (object, field, system, app) using Setup > Profiles or a data export tool / Metadata API.
- Document which users sit on which profiles and identify user personas / job functions.
- Flag profiles that are near-identical duplicates. These are prime candidates for consolidation.
Output: A permissions inventory spreadsheet mapping profile → permissions → users.
Step 2: Define Baseline Profiles
- Strip each profile down to only what must remain: login hours, IP ranges, default app, default record type, page layout assignments.
- Create a small set of lean baseline profiles (e.g. Standard Internal User, Partner Community User, Customer Community User).
Output: Lean baseline profiles with no permissions beyond defaults.
Step 3: Build Permission Sets and Permission Set Groups in Salesforce
- Create granular permission sets aligned to functional areas (e.g. Cases: Read/Write, Accounts: Read Only, Custom App Access).
- Group related permission sets into Permission Set Groups (PSGs) aligned to user personas (e.g. Support Agent PSG, Sales Rep PSG).
- Where needed, use Muting Permission Sets within a PSG to suppress specific permissions for a subset of users without creating a separate PSG.
Output: A library of reusable permission sets and PSGs that cover all previously profile-based access.
Step 4: Assign Permission Sets to Users / Roles
- Use User Access Policies to automate bulk assignment based on profile, role, or other user criteria.
- For smaller orgs, assign PSGs manually or via a data loader.
- Validate that each user persona (Admin, Support Agent, Sales Rep, Partner User, Community Member) has the correct PSG assigned.
Output: All users assigned to appropriate permission set groups in Salesforce, with baseline profiles attached.
Step 5: Test in Sandbox (UAT)
- Enable the ‘disable permissions on profiles’ option in your sandbox if available.
- Run critical user journeys for each persona: log in, access records, create/edit/delete operations, page visibility, app access.
- Test field-level security: verify that sensitive fields are hidden from users who should not see them.
- Test Experience Cloud site access for authenticated users, partner users, and guest users.
Output: UAT sign-off report for each user persona.
Step 6: Production Rollout, Monitoring, and Documentation
- Deploy changes to production during a low-traffic window.
- Monitor login errors, access complaints, and Apex exception logs for 48–72 hours post-deployment.
- Document your final permission set architecture: PSG-to-persona mapping, FLS decisions, and any Muting Permission Sets in use.
- Schedule a quarterly access review to keep permission sets clean and least-privilege.
Output: A documented, auditable, permission set-based user management architecture in production.
Why Switch from Profiles to Permission Sets in Salesforce
The migration is Salesforce-mandated, but the benefits extend well beyond compliance. Here is why making the switch now rather than at the last moment pays off for admins and their organizations:
- Granular, auditable access control: Permission sets are additive and explicit. You can see exactly which sets grant which permissions, and run access audits without reverse-engineering tangled profile hierarchies.
- Reduced admin overhead: Instead of maintaining 30 near-identical profiles, you maintain a handful of baseline profiles and a library of composable permission sets. Changes propagate cleanly.
- Least-privilege security: Permission set groups make it easier to implement role-based access control (RBAC). Muting Permission Sets let you suppress inherited permissions for edge cases without creating one-off profiles.
- Scalability: As your org grows (new user types, new apps, new data objects) permission sets scale gracefully. Adding a new persona is a matter of assembling existing permission sets into a new group, not cloning and modifying a profile.
Experience Cloud Specifics: What Admins Need to Know
Experience Cloud user permissions management has always had nuances that differ from internal user management, and the permission set migration amplifies this. Here is what to keep in mind for your Experience Cloud sites:
Authenticated External Users (Partner / Customer Community Users)
These users are assigned a Community profile. Historically, admins had to manually modify these profiles (or use Flows) to grant access to specific objects and fields. With permission sets, you can now assign fine-grained access on top of a lean community baseline profile, making ongoing access management far simpler and reducing the risk of accidentally over-permissioning all community users when you only need to grant access to a subset.
Guest User Access
Guest user access is governed by the Guest User Profile for each Experience Cloud site. Note that permission sets cannot currently be assigned to guest users. All guest access must remain on the guest profile. This is a critical distinction: be especially careful not to expose sensitive objects or fields via the guest profile. Regularly audit guest profile permissions as part of your security review.
Common Mistakes to Avoid
- Over-permissioning: Granting broad object access via a community profile ‘just to be safe’. Instead, use permission sets to grant only what is needed.
- Forgotten FLS: Field-level security is often set on profiles and not replicated into permission sets during migration, causing fields to appear blank or throw errors for community users.
- Guest access sprawl: Accumulating unused object permissions on guest profiles over time. Audit and trim regularly.
- Missing permission set assignments after user record creation: If you rely on manual assignment, new community users may lack the correct permission sets until an admin intervenes. Use User Access Policies Salesforce to automate this.
For a deeper dive into Experience Cloud access architecture, see our guide on Data Access and User Permissions in Experience Cloud.
Looking for Assistance? Get a Helping Hand Here!
To ensure the smoothest and most painless process, we recommend leaving this job to professionals. At Advanced Communities, we have a wealth of experience working with Salesforce and its products. We can help you with everything, from security auditnd migration plan to implementation and post-launch support. Reach out to us and book a call to discuss your case.
If you’re looking for robust solutions for your Experience Cloud, such as event management solution, comprehensive Salesforce knowledge management tool, or member management app for Salesforce Experience Cloud, we’re here to help.
FAQ
1. What is the difference between a Profile and a Permission Set in Salesforce?
A Profile is a required user record attribute that controls login access, UI defaults (default app, record type), and page layout assignments. A Permission Set is an optional, additive object that grants specific permissions (object CRUD, FLS, system permissions, app access) on top of a profile. The key difference is scope and flexibility: every user must have exactly one profile, but can have multiple permission sets. After Spring ’26, permissions can only be configured in permission sets, not profiles.
2. What should remain in a ‘baseline profile’?
A baseline profile should contain only the settings that cannot move to permission sets: login hours, trusted IP ranges, the default app, the default record type, and page layout assignments. All object permissions, FLS, system permissions, custom permissions, and app access should be removed from the profile and configured in permission sets instead. Aim for a small number of lean, clearly named baseline profiles (e.g. Standard Internal User, Partner Community Login User).
3. When should I use Permission Set Groups and Muting Permission Sets?
Use Permission Set Groups (PSGs) when you need to assign a consistent bundle of permissions to a user persona, for example, a ‘Support Agent’ PSG that includes Cases (Read/Write), Knowledge (Read), and Contact (Read). This is cleaner than assigning five individual permission sets to every support agent.
Use Muting Permission Sets when a small subset of users in a PSG should not have a specific permission that the group otherwise grants, for example, suppressing ‘Delete Case’ for junior agents within the Support Agent PSG, without creating a separate group.
4. How do I audit which permissions a user effectively has?
In Salesforce Setup, navigate to a user record and use the ‘View Summary’ button (where available) to see an aggregated view of their effective permissions across profile and all assigned permission sets. For a more comprehensive audit, the Permission Set Assignment report and the Object Permissions report in Setup provide exportable views. Third-party tools and the Metadata API can also export full permission matrices for large-scale analysis.
5. Is this change relevant for Experience Cloud users?
Yes. Experience Cloud user permissions are directly affected. Authenticated community users (Partner Community, Customer Community) can be assigned permission sets in addition to their community profile, and admins should migrate any object/field permissions currently on community profiles into permission sets. The exception is guest users: guest user access cannot be managed via permission sets and must remain on the guest profile.
6. What is the safest rollout approach for a large org?
For large orgs, the safest approach is a phased, persona-by-persona rollout in a full sandbox before touching production. Start with a low-risk, well-understood user type (e.g. read-only reporting users), validate thoroughly, then move to more complex personas. Use User Access Policies to automate permission set assignments so that new users automatically receive the correct access from day one. Enable the ‘disable permissions on profiles’ setting in sandbox to simulate post-EOL conditions and surface any gaps before they affect production users.
