Open the Setup menu in a Salesforce org that has been running for five or ten years and you will often find dozens of profiles — many of them clones of System Administrator, created years ago to solve a problem nobody remembers. Each clone carries broad permissions like View All and Modify All, and each one is a quiet security and maintenance risk.
The instinct to clean this up is right. The risk is doing it carelessly: profiles control more than object access, and ripping them out without a plan breaks page layouts, record types, apps, and user workflows.
This guide explains how Salesforce profile consolidation works, why permission sets are the better long-term model, and how to migrate safely without locking anyone out.
Salesforce profile consolidation is the process of reducing a sprawl of similar, over-permissioned profiles down to a minimal baseline set, then moving granular access control into permission sets and permission set groups. It matters for any org where profiles have multiplied over the years — especially where old profiles were cloned from System Administrator and carry far more access than users need. The safe path is to inventory what you have, analyze actual usage, design a permission-set-led target model, build and test it in a sandbox, and migrate users in controlled groups. Vantage Point runs this kind of security-model cleanup as part of its Salesforce health check and remediation work.
Profile consolidation is a security-model redesign project. Instead of maintaining dozens of profiles that each bundle object permissions, field permissions, record types, page layouts, and app assignments into one rigid container, you collapse profiles down to a small set of baseline profiles and express everything granular through permission sets and permission set groups.
A user then gets one baseline profile plus whatever permission sets their role requires. Two users on the same profile can have meaningfully different access without a new profile ever being created.
Profile sprawl is almost never the result of a decision. It accumulates:
The result is an org where a routine access request takes days, nobody can answer "who can see this field?" without research, and profiles carry broad View All and Modify All permissions that were never intentionally granted.
| Profile | Permission Set | Permission Set Group | |
|---|---|---|---|
| What it is | One baseline container per user (exactly one required) | A reusable bundle of permissions assigned on top of a profile | A named bundle of permission sets assigned as a unit |
| Best for | Baseline settings: page layout assignments, record type defaults, login hours and IP ranges | Object, field, app, Apex class, and connected app access for a role or task | Combining role-based sets (e.g., "Sales Team" = core selling + reporting + territory sets) |
| Quantity per user | Exactly one | Many | Many |
| Maintenance cost | High when used for granular access | Low; reusable across teams | Lowest for whole-role assignment |
The modern pattern: profiles carry only what must be singular per user, and everything else moves to permission sets and groups.
Salesforce announced in 2023 that permissions on profiles would reach end of life in the Spring '26 release, pushing all granular access control to permission sets. Salesforce has since cancelled that retirement — profiles continue to support permissions, and there is no enforced migration deadline.
The strategic direction is unchanged, though. Salesforce still recommends a permission-set-led security model, and most new user-management investment in Setup follows that model. Treat the cancelled deadline as breathing room, not as a reason to keep building on profiles. An org that consolidates now gets the security and audit benefits immediately and stays aligned with where the platform is heading.
Export every profile with its user count, and flag the usual suspects: profiles with one or two users, profiles whose names reference departed employees or old org names, and any profile carrying Modify All Data or broad View All permissions that isn't System Administrator.
A profile's permissions on paper matter less than what users actually do. Review login history, feature usage, and which record types and apps each group genuinely touches. Zero-usage fields and permissions that were granted "just in case" are your first consolidation wins.
Define a small set of baseline profiles — often one per license type or major user population — then map every distinct access need to a permission set, grouped by role. This is where you deliberately decide what each team should be able to do, rather than inheriting whatever a decade of cloning produced.
Build the new model in a partial or full sandbox first. Test as real users: page layouts, record types, default apps, list views, reports, integrations, and any automation that checks profiles or permissions. Pay special attention to anything that references a profile by name in validation rules, flows, or code — those references must be updated before users move.
Move one team at a time, with a rollback plan and a named contact for same-day issues. Hold a short hypercare window after each group migrates.
Once a profile has zero users, document it, wait an agreed period, then remove it. Keep a record of what each retired profile granted in case a legacy dependency surfaces later.
Start with measurement, not deletion. Run a profile and permission inventory, count how many profiles carry broad data access, and estimate the maintenance hours your team spends on profile-based access requests each quarter. That baseline turns "we should clean this up someday" into a scoped project with a payoff.
Then pilot the permission-set-led model with one well-understood team. A single successful migration builds the playbook — and the internal confidence — for the rest of the org.
Vantage Point's Salesforce consultants run structured access-model reviews: profiling your current state, designing a least-privilege target model, building it in a sandbox, and migrating users without disruption. For orgs that need ongoing governance after the cleanup, our managed services team keeps the permission model clean as roles evolve. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
If your org has years of profile sprawl — or an audit on the horizon — Vantage Point can assess your access model and deliver a safe consolidation plan. Talk to Vantage Point about a Salesforce health check.
No. Salesforce announced an end-of-life for permissions on profiles targeting Spring '26, then cancelled the retirement. Profiles remain fully supported, though Salesforce still recommends a permission-set-led security model for flexibility and scale.
There is no universal number, but a healthy consolidated org typically runs a small set of baseline profiles — often one per license type or major user population — with granular access handled by permission sets. Dozens of team- or person-specific profiles is a reliable sign of sprawl.
A user has exactly one profile, which controls baseline settings like page layout assignments, record type defaults, and login restrictions. Permission sets are reusable bundles of permissions layered on top of the profile, and a user can hold many of them.
Page layout assignments, record type defaults, default apps, homepage assignments, and login hour or IP range restrictions all follow the profile. Any validation rule, flow, code, or integration that references the old profile by name can also fail, which is why testing in a sandbox matters.
No. The retirement was cancelled, so there is no deadline — but the security, audit, and maintenance benefits of consolidation are available now, and Salesforce's platform direction still favors permission sets. Waiting simply extends the risk window.
It is strongly discouraged. Profile changes touch layouts, record types, and automation, and mistakes surface as locked-out users or broken pages. A partial or full sandbox lets you validate the new model with real users before anyone's access changes in production.