Moving to permission sets means shrinking every profile to a thin base of login and display settings. All real access then comes from permission sets bundled by job function. Salesforce no longer plans to force the change, but it still recommends this model and has said profiles will not get new improvements. The safe route is to inventory current access, design personas, rebuild access in a sandbox, compare results user by user, then pilot before switching everyone.
Is Salesforce still retiring permissions on profiles?
No. The retirement was announced and later cancelled, so profiles keep working, though Salesforce continues to steer customers toward permission sets.
The history matters because many teams paused or rushed projects around it. In January 2023, a post on the Salesforce Admins blog signalled that permissions on profiles would reach end of life in Spring '26. That plan was later dropped. A Salesforce Help knowledge article titled Permissions in Profiles Retirement Cancelled states the enforcement was called off after customer feedback and remaining feature gaps. Trade coverage of the reversal appeared in July 2026.
The same article still recommends a least-privilege model: profiles for baseline settings, permission sets and permission set groups for access. The Admins blog post added a note saying Salesforce will not invest further in profiles. Treat that as direction rather than deadline, and check Salesforce Help for later updates before you plan around any date.
Why bother migrating if profiles still work?
Because profile sprawl makes access hard to explain, hard to change and hard to audit. Permission sets fix that by separating who a user is from what they can do.
A profile is all-or-nothing: each user gets exactly one. When a sales manager needs one extra report permission, admins often clone the whole profile. Repeat that for a few years and an org carries dozens of near-identical profiles. Nobody can say which differences are deliberate.
Permission sets are additive and stackable. You can give one person one extra capability without touching anyone else. When an auditor asks why someone has a right, you point at a named set tied to a named duty.
- Onboarding gets faster, because new hires receive a role bundle instead of a hand-built profile.
- Role changes stop requiring profile swaps that silently remove page layouts or login settings.
- Access reviews become a list of sets per person, which managers can actually read and sign off.
- Deployments shrink, since a change to one capability touches one small set rather than many profiles.
What should stay on the profile?
Keep only the settings permission sets cannot carry, and start from Salesforce's Minimum Access – Salesforce profile or a clone of it.
The profile still owns a handful of defaults: page layout assignments, login hours, login IP ranges, session settings, default record types and default apps. Most orgs end up with a very small number of base profiles. Typical splits are internal staff, integration users and any group needing distinct login restrictions.
Everything else moves out. That covers object and field permissions and user permissions such as Export Reports. It also covers Apex class and Visualforce access, tabs, custom permissions and connected apps. If a capability can live in a permission set, put it there.
How do permission set groups and muting fit together?
A permission set group bundles the sets one job needs into a single assignment. A muting permission set inside that group switches off selected permissions for the group's members only.
Build small permission sets around capabilities, such as Opportunity Management, Quote Approval or Case Escalation. Then assemble groups around roles, such as Account Executive or Service Team Lead. One set can sit in many groups, so a change to Quote Approval flows to every role that uses it.
Muting handles the exceptions. Suppose the Service Agent group should include a shared Case Management set but not its delete right. Add the delete permission to the group's muting set instead of forking the shared set. Salesforce Help notes a group can hold only one muting set. Muting also leaves untouched any user who gets the same set assigned directly, outside the group.
How do you design access by job function?
Start from what people do, not from who they report to. Define personas from real tasks, then map each persona to the capabilities it needs.
Interview a few people per team and watch how they actually use the org. Write each persona as a short list of verbs and objects: creates opportunities, edits own accounts, views commission fields, exports pipeline reports. Shared verbs become shared permission sets; unusual ones become small add-on sets.
Keep visibility separate in your head. Permission sets control what a user can do with an object or field. Whether they can see a particular record still depends on org-wide defaults, roles and sharing rules. A clean permission design will not fix an over-shared record model, so note sharing issues for a separate workstream.
- Name sets by capability and groups by role, so the purpose is obvious from the name alone.
- Write a one-line description on every set and group explaining which duty it supports.
- Avoid one set per person; if a set has a single member, question whether it should exist.
- Record an owner for each group who approves new assignments.
Can assignments be automated?
Yes. User access policies, which Salesforce Help lists for Enterprise and Unlimited editions (confirm coverage on the newer Core, Advanced and Max editions), can grant or revoke access automatically based on user record criteria.
A policy can assign permission sets, permission set groups, permission set licenses, package licenses, public groups and queues. Active policies run when a user is created or updated, so a change to department or role field can move access with it. Manual policies apply a one-time bulk change to selected users.
Policies only work if the user record is trustworthy. Clean up department, title and any custom persona field first, and decide which system owns those values. Flow-based assignment remains an option where policy criteria are not expressive enough. Policy limits and edition coverage can change, so confirm both with your Salesforce account team early.
How do you migrate without breaking anyone's access?
Capture each active user's effective access and rebuild it in a sandbox. Prove every user keeps equal or deliberately reduced access, then roll out in waves.
| Step | What you do | Evidence it worked |
|---|---|---|
| 1. Inventory | Export profiles, permission sets, assignments and the users on each; flag powerful permissions | A baseline file of effective access per active user |
| 2. Define personas | Group users by job duties and agree the capabilities each persona needs | Persona list signed off by team leads |
| 3. Build in sandbox | Create capability sets, role groups, muting sets and a minimum-access base profile | Metadata in source control, reviewed like any other change |
| 4. Compare access | Diff each user's old effective access against the new model | Every gain or loss is listed and explained |
| 5. Test as users | Log in as representative users and run their daily tasks end to end | Test scripts passed for each persona |
| 6. Pilot | Move one team in production and watch for errors and help requests | A quiet week of normal work, or a short fix list |
| 7. Roll out in waves | Move remaining teams, then retire unused cloned profiles | Profile count down, no orphaned assignments |
| 8. Keep a rollback | Hold old profile assignments and a scripted way to restore them | A rehearsed restore for the pilot group |
The comparison step is where projects succeed or fail. Effective access is the union of the profile and every assigned set, so compare at that level rather than profile against group. Expect to find access nobody can justify. Removing it is a business decision, so get team leads to agree before cutover rather than discovering it through a support ticket.
Rollback is easier than it sounds. Until you delete the old profiles, reverting a user means restoring their prior profile and removing the new group assignment. Keep the cloned profiles, untouched, until the last wave has settled.
Which tools help with the conversion?
Salesforce's free User Access and Permissions Assistant, installed from AgentExchange (formerly AppExchange), covers much of the heavy lifting. Spreadsheets and metadata diffs fill the remaining gaps.
Per Salesforce Help, the assistant converts a profile into an editable permission set. It also reports on who holds which permissions and manages permission set groups. It is listed for all editions except Starter. Its documentation notes that a conversion does not carry over record types or tab settings, so check those by hand afterward.
A converted profile is a starting point, not a finished design. It reproduces today's sprawl inside a permission set. Use it to capture the baseline, then split the result into capability sets that match your personas.
How should you audit access after the switch?
Review high-risk permissions and group membership on a fixed schedule, and make the group owner confirm each assignment.
Pick a cadence, such as quarterly, and generate a list of users per group plus anyone holding directly assigned sets. Direct assignments outside a group are the drift to watch: each one should have a reason and an end date. Re-run the powerful-permission search from your original inventory and compare it to the previous quarter.
Wire access into joiner, mover and leaver processes as well. A department change should trigger a user access policy or an admin task, never just a manager's email. Our security review checklist covers the wider audit, from MFA to connected apps.
How does this support Agentforce and AI least privilege?
AI features act through a Salesforce user, so they inherit whatever that user can reach. Tight, role-based permission sets are the practical way to limit what an agent can read or change.
Salesforce Help says an Agentforce service agent user is created with minimal access and should be expanded only as needed. Recommended setup uses the Einstein Agent User profile plus agent-specific permission sets. That mirrors the model in this guide: a thin base profile and narrowly scoped sets for each job the agent performs.
Employee-facing AI features run as the signed-in person, so a sprawling profile gives an assistant the same sprawl. Cleaning up permissions before an Agentforce rollout is often the cheapest security control available.
What mistakes cause migrations to stall?
Most stalls come from copying old sprawl into new containers or skipping the user-level comparison.
- Converting every profile one-to-one and calling it done, which keeps the clutter under a new name.
- Building hundreds of tiny sets with no groups, which makes assignments as hard to read as before.
- Forgetting default record types and apps, so users open the wrong page after cutover.
- Testing only as a system administrator, which hides every gap a real user would hit.
- Leaving integration users on full profiles instead of a minimum-access integration profile with scoped sets.
- Deleting old profiles before the final wave has run cleanly, removing the easy rollback path.
If your org needs a broader view first, a Salesforce health check will show how much access cleanup to plan alongside other technical debt.
