It starts small. A sales rep needs temporary access to a restricted object to close a deal, so permission is granted but never revoked. A manager moves into a new role but keeps the access from their previous one. A consultant is given admin rights during an implementation and never walked back. A permission set is cloned without anyone checking what the original contained.
Individually, none of these decisions feel significant. Collectively, they produce an access landscape that no one designed and no one fully understands. This creates risk in ways that rarely surface until something goes wrong.
How permission sprawl happens
Salesforce’s security model is genuinely complex. Profiles, permission sets, permission set groups, role hierarchies, sharing rules, field-level security, object access – each layer interacts with the others in ways that aren’t always intuitive, even to experienced admins. In an org still finding its feet, this complexity is manageable. In an org that’s been running for five or ten years, with dozens of admins, hundreds of users, and a history of one-off configuration decisions, it becomes almost impossible to hold a complete picture of who can see and do what.
What makes this so persistent is the absence of friction. Salesforce admins are typically focused on keeping the business moving – onboarding new users, supporting sales cycles, enabling new workflows. Granting a permission takes seconds. Auditing whether it should still exist requires time and tooling that most teams don’t have. The result is a one-way ratchet: access gets added continuously, and it almost never gets taken away.
There is rarely a single owner responsible for the overall access posture of the org. Without that ownership, no one is asking the question that matters most: does this person still need this?
“Admins grant object-level View All/Modify All (or the org-wide View All Data/Modify All Data) to solve a narrow reporting or integration need, then never scope it back. This silently overrides all sharing rules, OWD, and record-level restrictions for every user holding that permission set,” says Tapas Tripathi, Salesforce Architect at Cloud Protection for Salesforce.
Why it rarely gets fixed
The root problem is visibility. Most organizations don’t have a clear, current map of who has access to what in Salesforce. Native reporting can surface some of this information, but gaining a meaningful picture of effective permissions – accounting for the interaction between profiles, permission sets, and sharing rules – requires significant manual effort. For most teams, that effort is hard to justify until something goes wrong.
There’s also an organizational gap. Access reviews are standard practice for Active Directory and core infrastructure. For Salesforce, the same rigor rarely applies. It doesn’t fall cleanly under IT security, Salesforce administration, or compliance, so it tends to fall between them. The result is that permission configurations that would fail a basic least-privilege audit sit untouched for years, simply because no one is looking.
“Instead of building least-privilege profiles, teams clone the admin profile and strip a few checkboxes. Because the base is so permissive, things like Manage Users, Modify All Data, Author Apex, or Customize Application often survive the cleanup unnoticed,” Tripathi states.
The impact when it goes wrong
Over-permissioned accounts don’t create breaches. Instead, they determine how bad they are. A phishing attack that lands on a standard user account is a bad day. The same attack on an account carrying system administrator rights, modify-all access, or broad data export permissions is a categorically different incident: full visibility into your pipeline, the ability to exfiltrate or destroy records at scale, and potentially a path into connected systems. The permission model doesn’t just define what users can do. It defines the blast radius when something goes wrong.
The same applies to insider risk. A departing employee with standard sales rep access can do damage. One with elevated permissions, accumulated over years of tenure, can do considerably more. And because permission sprawl is invisible, the security team often doesn’t know what they were capable of until after the fact.
Misconfiguration is also a factor. Overly permissive sharing rules can inadvertently expose records to users who have no business reason to access them. Field-level security gaps can leave sensitive data, such as contract values, personal information, strategic account details, visible to a far wider audience than intended.
The takeaway
Closing the permission gap starts with getting visibility. That means being able to see the effective access of every user in the org. This means not just their assigned profile, but the combined result of every permission set, sharing rule, and role hierarchy entry that applies to them.
From there, it requires a regular review cycle: a structured process for identifying access that no longer reflects current roles, flagging dormant accounts, and ensuring that exceptions granted for specific circumstances don’t become permanent. This isn’t a one-time project, it’s an ongoing discipline and needs tooling that makes the process manageable rather than a manual exercise that nobody has time for.
The permission gap is quiet, unglamorous, and almost entirely preventable. That’s exactly what makes it worth talking about.