Permission sets vs profiles: where over-access usually hides
Profiles and permission sets are two ways to grant the same things: object permissions, field permissions, and system permissions like View All Data. Because they grant the same things, it is easy to treat them as interchangeable. How you manage them, though, is where over-access tends to collect, so the distinction is worth getting right.
The short version of the difference
Every user has exactly one profile, and the profile is meant to carry the baseline a whole category of users shares. Permission sets are additive grants layered on top, and a user can have many. The modern guidance from Salesforce is to keep profiles lean and do most granting through permission sets and permission set groups, because additive, named grants are easier to assign, reason about, and remove than a thicket of differing profiles.
Why over-access hides here
A few ordinary patterns push access wider than intended:
- A permission is added to a profile to unblock one user, and now everyone on that profile has it.
- A powerful permission like View All Data or Modify All Data is granted in a permission set created for a narrow task, then the set gets assigned more broadly over time.
- Permission set groups bundle several sets together for convenience, and a strong permission rides along inside the bundle where no one expects it.
- A user keeps a permission set from a previous role because removing access is nobody’s job and rarely gets noticed.
Each of these is the system working as designed. The risk is not a bug. It is that powerful permissions are easy to grant, easy to inherit through a group or a profile, and almost never reviewed for whether they are still needed.
The permissions most worth watching
A handful of permissions cut past your entire sharing model. View All Data and Modify All Data ignore org-wide defaults, the role hierarchy, and sharing rules entirely. Their per-object versions, View All and Modify All, do the same for one object. Manage Users, Customize Application, and Author Apex are powerful in different ways. None of these are wrong to grant. They are simply the ones where “who has this, and why” is the question most worth being able to answer at any time.
Tracing a permission back to its source
The hard part is that a user’s effective permissions are the union of their profile and every permission set and permission set group they hold, and Salesforce does not show that union from the record’s perspective. When you find a user who can see everything, the useful next question is which grant did it: the profile, a specific permission set, or one tucked inside a group.
That is a question Who Sees What is built to answer. When it shows that a user has broad access, it names the source, the profile or the exact permission set granting it, and it resolves permission set groups down to the set inside them that carries the permission. So “this person can see all the data” becomes “this person can see all the data because of this permission set, which they have because of this group,” which is something you can actually act on.
Lean profiles, additive permission sets, and a habit of asking “who has the powerful permissions, and why” will keep most orgs close to least privilege. The rest is being able to follow any grant back to its source whenever you need to.