Permission sets and profiles both grant access in Salesforce, but they are not interchangeable and Salesforce has said so for years. The fix is simple: every user gets one minimal profile that handles login hours, IP ranges, and record types. Every permission grant beyond that lives in permission sets. If your org still builds fifteen profiles to express fifteen job roles, you are maintaining a mess that permission sets were built to kill.
A profile is a single object assigned to a user. One user, one profile, no exceptions. That constraint made sense in 2005 when org complexity was low and admins managed a few dozen users. It stopped making sense once companies started running hundreds of users across sales, support, finance, and partner portals, each needing slightly different object access.
The result was profile sprawl. Admins cloned profiles to add one field permission, then cloned again for one more. Orgs ended up with forty profiles that differed by a single checkbox, and nobody remembered which checkbox mattered six months later. Auditing that mess means opening each profile individually and comparing settings by eye.
Permission sets fix the structural problem, not just the symptom. A user can hold one profile and any number of permission sets at the same time. Access becomes additive. You stop cloning entire profiles to grant one extra permission and instead layer a small, named permission set on top of a shared baseline profile.
Permission sets vs profiles debates often overstate how much profiles can be retired. A handful of settings are profile-only and will not move to permission sets no matter how recent your release notes are.
Permission set groups and the newer session-based permission set mechanics have closed some gaps, but record type defaults and login restrictions are still profile territory as of current Salesforce releases. Build your profile strategy around these leftovers, not around object CRUD, which belongs entirely in permission sets.
The pattern that works at scale is boring on purpose. Create a small number of base profiles, usually three to six, organized by license type and login constraints: Standard User, Sales Rep, Support Agent, Partner Community User. Strip every object permission out of these profiles that you possibly can. Leave only what profiles are forced to carry.
Then build permission sets around function, not person. A Opportunity Edit Access permission set. A Case Escalation permission set. A Finance Reporting permission set. Assign these in combination to users based on what they actually do, not what profile template seemed closest when they were onboarded.
This is where permission set groups earn their keep. Bundling ten individual permission sets into one group called Senior Support Agent means you assign one thing at onboarding instead of ten. When a new permission needs to apply to every senior support agent, you add it to the group once, and every member inherits it instantly. That single change used to mean editing a cloned profile and hoping no one else depended on the old version.
Object permissions migrated to permission sets years ago without much resistance. Field-level security lagged, because admins had already built muscle memory around setting field visibility inside profiles, object by object, field by field. That habit is the single biggest source of permission sprawl left in mature orgs.
Move field-level security into permission sets and the payoff compounds. A new confidential field gets added to Opportunity. Instead of opening forty profiles to hide it from the wrong audience, you create one permission set called Opportunity Confidential Field Access and grant it to the three roles that need it. Everyone else never sees the field, and you never touched a profile.
Salesforce's own Optimizer tool and the permission set usage reports under Setup will flag profiles where field-level security still does heavy lifting. Run that audit before you touch anything else. It tells you exactly where the real cleanup debt sits, instead of guessing.
Muting permission sets solved a real problem: what happens when a permission set group grants something you specifically do not want one user to have. Before muting existed, the answer was to clone the whole group and strip the unwanted piece, recreating the exact sprawl permission sets were supposed to eliminate.
Now a single muting permission set inside a group can suppress one specific object permission or field permission without touching the rest of the bundle. This matters more than it sounds. It means the exception case, the one contractor who needs everything except delete access on Contracts, no longer forces you to fork your entire permission architecture for one person.
Cloning still has a place for profiles when login hour or IP restrictions genuinely differ between two groups of users. That is a legitimate reason to maintain a second base profile. Cloning a profile to add one more object permission is not a legitimate reason anymore, and if you catch yourself doing it, stop and build a permission set instead.
Do not attempt to flatten every profile to bare minimum in one weekend. Salesforce access is the kind of system where a mistake does not surface until a VP cannot see their own pipeline on a Monday morning, and by then you have lost the afternoon to triage.
Start with new hires. Build the minimal-profile-plus-permission-sets pattern for every new user going forward, and leave legacy users on their existing cloned profiles untouched. This gets your new growth clean without touching anything load-bearing.
Next, pick one object with the worst profile sprawl, usually Opportunity or Case, and migrate its field-level security and object permissions into permission sets for a single department. Measure the time it takes to make one access change before and after. That number is what you show leadership to justify the rest of the migration.
Finally, work backward through legacy profiles one at a time, converting each to the minimal pattern and retiring the clone once every user on it has been reassigned. Keep a spreadsheet of who held which profile before the change, because permission regressions are real and you want a fast rollback path, not a guessing game.
No. Every Salesforce user is assigned exactly one profile at a time, with no exceptions. This is the main structural limit that pushed Salesforce to build permission sets, which can be stacked in any number on top of a single profile.
Login hours, login IP ranges, default record types, and default app assignments remain profile-only settings. Everything else, including object permissions and field-level security, can and generally should live in permission sets instead.
Permission sets add access on top of a profile, they do not remove or override restrictions the profile already has. If a profile hides a field entirely, a permission set can grant visibility to that field, but it cannot restrict something the profile already allows unless you use a muting permission set inside a permission set group.
A permission set group bundles multiple individual permission sets into one assignable unit, so an admin can grant a whole role's access in a single click instead of assigning ten separate permission sets. Updates to the group propagate to every user who holds it, which keeps role-based access consistent as requirements change.
Yes, especially if the org has accumulated many near-duplicate cloned profiles over the years. The payoff is faster, safer access changes and easier audits, but the migration should happen gradually, starting with new users and one object at a time, rather than all at once.