Profiles Are Fading: A Practical Move to Permission Sets

Salesforce has been quietly repositioning profiles for years. The message is clear now: profiles are a baseline. The future is permission sets and permission set groups.

The shift makes sense. Profiles are monolithic. If two users have the same job but one needs an extra feature, they can't share a profile — you have to clone it, modify it, and maintain two profiles forever. Permission sets are modular. You stack them on top of a baseline profile. Sales Role gets Salesforce CRM Base, then add Sales Cloud Features, then add Forecasting, then add Einstein Analytics. Three permission sets, one profile.

It's also where Salesforce is investing. New features often only appear in permission sets, not profiles. If you want to grant Assign Permission Sets, Create Apps, or API Limits, you're assigning permission sets, not editing profiles.

If your org still runs on profiles, the migration is inevitable. Here's how to do it safely.

---

The Permission Model: Profile + Permission Sets + Permission Set Groups + Muting PS

A user's effective permissions are the sum of four sources:

• Profile — The baseline. Every user must have a profile. It grants the foundational permissions for their role (standard object CRUD, basic features).
• Permission Sets — Feature-based add-ons. You stack these on top of the profile to grant specific capabilities (Forecasting, Content, API access). One permission set = one feature.
• Permission Set Groups — Bundles of permission sets. Instead of assigning ten permission sets individually, you assign one permission set group that contains those ten. It's a convenience layer.
• Muting Permission Sets — Permission sets that subtract permissions from the profile or assigned permission sets. If your profile grants Modify All Data but you want to remove it for a specific user, you assign a muting permission set that has "Modify All Data: False," and it revokes the permission.

Most orgs run on just profile + permission sets. Permission set groups make sense if you have large stacks (10+ permission sets per user).

---

Migration Strategy: Phase by Phase

Phase 1: Inventory Current Profile Permissions

Audit your existing profiles. For each profile, document:

• System permissions (Create Users, Author Apex, Modify All Data, etc.).
• Object-level CRUD and View All / Modify All.
• Tab visibility (standard and custom).
• Admin or custom user license type.

Export this to a spreadsheet. You'll use it to group users by job function.

Phase 2: Group Permissions by Job Function

Look at your profiles and user base. If you have a "Sales User" profile and 60 users on it, they don't all have identical needs. Some need Forecasting. Some need Territory Management. Some need Einstein Analytics.

Create job function groups:

• Sales Rep (standard Salesforce CRM Base)
• Sales Manager (+ Forecasting, + Reports, + Dashboards)
• Sales Engineer (+ Forecasting, + Knowledge, + Contracts)
• Support Agent (+ Cases, + Knowledge, + Chat)
• Admin (+ Customize Application, + Manage Users, + Author Apex)

For each group, document the permissions they actually need.

Phase 3: Build Feature-Based Permission Sets

Create permission sets, not by role, but by feature:

• "Salesforce CRM Base" — Read/Create/Update on Accounts, Contacts, Opportunities, Tasks, Events (this replicates what the profile grants).
• "Forecasting" — Forecast object CRUD, Forecast Namespace API.
• "Reports and Dashboards" — Report and Dashboard CRUD, folder access.
• "Einstein Analytics" — Analytics Cloud API, Insight object access.
• "API Access" — API Enabled permission.

One permission set = one feature. This makes it easy to audit and update — if the Forecasting permission set is broken, you fix one place, not ten profiles.

Phase 4: Validate Effective Access

Before you cut over any users, validate that their new permission stack grants the same access as their old profile. This is where Persona Simulator is essential.

For a test user, assign them the new permission set stack (keep the profile they're on, remove the old profile's extra permissions, add the permission sets). Then run Persona Simulator and compare:

• Same objects readable and writable?
• Same tabs visible?
• Same system permissions?
• Same record-level access (if your org uses sharing rules)?

Persona Simulator shows you the effective access — Profile + all assigned Permission Sets + all assigned Permission Set Groups + all assigned Muting Permission Sets resolved into one verdict. If it matches the old profile, you're safe to migrate the user.

Phase 5: Migrate Users and Retire Old Profiles

Roll out in waves:

• Week 1: Admins (easiest, smallest group, can help if something breaks).
• Week 2: Power users (developers, process builders, flow authors).
• Week 3: Standard users (largest group, most risk, most testing done by now).
• Week 4: Contractors, partners, and API integrations.

For each wave, assign the new permission set group or stack, validate in Persona Simulator that access is identical, and monitor for a week. If everything is stable, remove the old profile assignment.

Once all users are migrated off a profile, retire it. Don't delete it — archive it or mark it obsolete. You might need it as a reference.

---

Tools That Make This Safe

Permission Builder

Permission Builder is a visual, dependency-aware tool for building permission sets. Instead of clicking through Setup's cryptic checkboxes, you:

• Select objects you want to grant access to.
• Click which permissions you need (Create, Read, Update, Delete, View All, Modify All).
• See object dependencies visualized as a graph (if your permission set grants Opportunity, the graph shows Account as a parent dependency and Opportunity Teams as a related dependency).
• Preview the permission set before you save it.
• Bulk-edit multiple permission sets at once.

It saves hours on permission set design and prevents mistakes (like forgetting to grant Read access to Accounts when you grant Create access to Opportunities).

Persona Simulator

Persona Simulator is how you validate effective access before and after migration. For any user, it builds a 360-degree view of their permissions:

• Their profile's CRUD matrix.
• Every assigned permission set's CRUD matrix.
• Every permission set group's stacked permissions.
• Every muting permission set's subtractions.

It shows you the combined effect — the exact objects and fields they can read and write, the exact system permissions they have, the exact apps they can access. If the profile-based version and the permission-set-based version show the same effective access in Persona Simulator, you're safe to migrate.

It also lets you experiment: assign a test permission set and see the before/after side-by-side.

---

Post-Migration: The Permission Set Maintenance Strategy

After migration, you'll need ongoing maintenance. Every time you need to grant a new feature to a user:

• Check if a permission set for that feature exists. Assign it.
• If not, create one. Build it modularly so other users can reuse it.
• Don't clone profiles and modify them. Don't create one-off permission sets. Maintain a small library of features and reuse.

Over time, you'll have 30–50 permission sets, organized by feature, that cover every capability in your org. New users and features are additive. You don't maintain 100 profiles. You maintain 50 permission sets that are reassigned and recombined.

It's a cleaner, more maintainable model. It's also where Salesforce is heading.

---

Getting Started

Use Permission Builder to design your permission sets, and Persona Simulator to validate that effective access is preserved during migration.

See Permission Builder and Persona Simulator for detailed walkthroughs.

For a deep dive on the 10 layers of access that permission sets control, read The 10 Layers of Salesforce Record Access.