A few years ago we took over an implementation that a a Vietnamese conglomerate client had been running internally for about three years. The first thing we did was pull a list of profiles. There were 34 of them. When we started comparing them side by side, the pattern became immediately obvious: "Sales Rep," "Sales Rep with Export," "Sales Rep with Export and Merge," "Sales Rep Agentforce Pilot," and on down the list — each one a clone of the previous with a single checkbox flipped. Nobody had done anything wrong intentionally. The org had just grown the way orgs grow when nobody draws a line between what belongs in a Profile and what belongs in a Permission Set.
That project is the reason we now open every new engagement by establishing that boundary on day one.
The Profile is a floor, not a ceiling
Every Salesforce user must have exactly one Profile, always. You cannot assign zero profiles, and you cannot stack two. Because of that constraint, the Profile has to answer a specific question: what is the absolute minimum this category of user should be able to do in the org? It is a floor, not a description of everything the user will ever need.
Concretely, a Profile controls object permissions (Create, Read, Edit, Delete, View All, Modify All), Field-Level Security on every field, which Lightning Apps appear in the App Launcher, tab visibility settings, system permissions like "Manage Users" or "View All Data," and Connected App and Apex class access in certain configurations. It also controls two things that nothing else in the security model can touch: Login Hours and Login IP Ranges. Those two settings are profile-only, full stop — no Permission Set can override them, and we'll come back to why that matters.
The practical implication is that the Profile needs to be set conservatively. If you give a Sales Rep profile the ability to export data because three reps need it, you've given it to every rep who ever gets that profile, forever. We always ask: is this permission something every single user in this category should have on their first day? If the answer is anything other than a clear yes, it does not belong in the Profile.
Profile proliferation is the most common thing we fix
When we audit an org that has been running without Permission Sets, the tell is always the same: a long list of profiles whose names read like a changelog. The org started with two or three sensible profiles, then someone needed one extra permission, so a new profile got cloned. Then another variation. Then a pilot program. After a couple of years, the org has 30 profiles that are all 95% identical and nobody is confident enough to consolidate them because they can't tell what's actually different between them without a manual field-by-field comparison.
The correct architecture is almost always far simpler: one profile per broad user type (Sales Rep, Service Agent, System Admin, Read-Only Community User — that kind of granularity), then Permission Sets for every variation above that baseline. We've taken orgs from 40 profiles down to 6 without changing what any user could actually do, just by moving the variation out of profiles and into Permission Sets where it belongs.
Permission Sets: everything the profile doesn't cover
A Permission Set is a bundle of permissions that gets assigned to individual users on top of their Profile. The effective permission for any user is the union of their Profile and every Permission Set they've been assigned — in practice:
Effective permission = Profile + all assigned Permission Sets
The critical constraint is that this model is additive only. A Permission Set can grant a permission the Profile lacks. It cannot take away a permission the Profile already grants. If the Sales Rep profile grants "Create Account," there is no Permission Set that undoes that. The only lever for removing a profile-level permission is editing the profile itself or moving the user to a different profile.
This is why we insist on conservative profiles. The whole model only works cleanly if the floor is low enough that Permission Sets have room to build on top of it. An org where profiles are already over-permissioned can't benefit from Permission Sets the way it should.
In practice, we use Permission Sets for three recurring scenarios. The first is temporary access — a business analyst at a Vietnamese telecom client needed View All Data for a three-month data quality audit, so we assigned a "Data Auditor" Permission Set and revoked it when the audit was done. No profile touched, no audit trail contaminated by a permanent change. The second is feature rollouts — when a client wanted to pilot Agentforce with 20 of their 200 sales reps, the Permission Set went to those 20. When the pilot succeeded, we bulk-assigned it to the rest. The third is role-specific additions — sales managers who need to delete Opportunities that reps cannot delete get a "Opp Deleter" Permission Set rather than a separate profile, which means they share the same baseline profile as their reps and we only maintain one set of base settings.
Permission Set Groups: managing combinations at scale
Once an org has 15 or 20 Permission Sets, you start running into a different problem: certain users need the same combination of five or six sets, and assigning them individually to 200 users is tedious and error-prone. Permission Set Groups solve this by letting you bundle multiple Permission Sets into a single assignable unit.
The operational advantage becomes clear the first time something changes. If one of the five sets in a Group needs to be updated or swapped out, you update the Group once — everyone assigned the Group picks up the change automatically. Without a Group, you're touching 200 individual user records. We always build Groups for any combination that applies to more than a handful of users.
Groups also support a mechanism called Muting Permission Sets, which suppresses specific permissions granted by members of the Group without removing those permissions from the individual sets themselves. It's a more advanced pattern, but it's useful when a Group grants broad access and a narrow subset of users in the Group shouldn't have one specific permission within it — a cleaner solution than maintaining a separate profile or a parallel Group.
The Login Hours exception
Because Login Hours and Login IP Ranges are profile-only, they create the one scenario where cloning a profile is genuinely the right answer. If a group of users needs to be restricted to specific login times or IP ranges, and the rest of the org is unrestricted, those users need a separate Profile. There's no Permission Set workaround. We're explicit about this with clients because it surprises people — the permission model is additive almost everywhere, and this is the one place where a structural difference in users truly does require a structural difference in profiles.
How we approach this on every project
Our standard for any new implementation is to start by mapping user types to the minimum permission set that describes their day-to-day work, create one Profile per type, and document clearly why each Profile exists. Everything above that minimum goes into a Permission Set with a name that describes its purpose, not its history. We never create a Permission Set called "Sales Rep Plus" — we create "Export Data Access" or "Opportunity Delete" so that six months from now it's still obvious what it does and who should have it.
The org we inherited with 34 profiles took about two sprints to rationalize. The org we helped design from scratch at a 600-person a large enterprise client is running with 7 profiles and about 25 Permission Sets, and adding a new permission variation takes a single Permission Set and a handful of assignments rather than a profile clone and a multi-week change process. The difference in maintenance overhead is not subtle.
Get the boundary right early. The Profile is the floor. Permission Sets build the rest.
