SALESFORCE PERMISSION SET SPRAWL: HOW TO REVIEW ACCESS BEFORE IT BECOMES RISK.

Most Salesforce orgs start with a manageable access model: a handful of profiles, a few permission sets for exceptions, and reasonable visibility into who can see what. Then projects happen. Roles change. Teams ask for temporary access that never gets removed. Consultants clone permission sets. Admins add exceptions to avoid breaking something mid-project.

Over time, permission sets stack on top of profiles. Nobody is fully sure who can see or edit which fields. Access that was temporary becomes permanent. And when someone finally asks what permissions a user has, the answer requires manually tracing through profiles, permission sets, object permissions, FLS, and user assignments.

That is permission set sprawl. And the risk is not only that too many permissions exist. The risk is that the team cannot explain them.

Salesforce permission set sprawl is the accumulation of overlapping, stale, or poorly documented permission sets that make it difficult to understand who has access to which objects, fields, and system capabilities.

It happens in patterns that are familiar to any admin who has worked in a long-running org:

• Project-specific permission sets created for a launch and never cleaned up
• Temporary access granted for a consultant or contractor that was never revoked
• Permission sets cloned from other permission sets without reviewing what they include
• Multiple overlapping permission sets assigned to the same user
• Old exception access from a role or team change that nobody removed
• Role changes where the user kept the old permission sets in addition to new ones
• Inherited orgs where nobody knows why specific access was granted
• Permission sets that exist but have no active assigned users, or are assigned to only one user with no clear ownership

The result is an access model that is technically in Salesforce but practically invisible to the team responsible for it.

The practical risks of permission set sprawl show up across audit, security review, and day-to-day admin work:

• Users keep access after role changes, departures, or team restructures
• Sensitive fields become readable or editable by more users than intended
• Object-level access expands unintentionally through stacked permission sets
• Admins hesitate to remove any access because they cannot trace the downstream impact
• Security or compliance audits become slow and manual when there is no structured access inventory
• Consultants spend discovery time reconstructing the access model instead of focusing on the engagement
• Leadership asks for access cleanup but the team does not have enough evidence to know what is safe to change

The risk is not only that too many permissions exist. The risk is that the team cannot explain them.

An access model that cannot be explained cannot be reviewed deliberately. That is when access review stalls, and when cleanup decisions get made without enough evidence.

A common mistake in Salesforce access review is treating the profile as the complete picture of what a user can do. Profiles are one layer. They are not the whole story.

A complete access review needs to include all of the following:

• Profiles: the baseline access model for a user
• Permission sets: additional access layered on top of profiles
• Permission set groups, where applicable: bundled permission sets assigned as a unit
• Object permissions: Create, Read, Edit, Delete, View All, Modify All per object
• Field-level security: which fields a user can read or edit
• User assignments: which users are actually assigned each profile and permission set
• External, community, or guest-style users, where applicable
• System permissions: capabilities that go beyond object and field access
• Managed package permissions: access granted by installed packages

Missing any of these layers means the access review is incomplete. Over-privileged access can exist in any of them. For the checklist version of this review, see the Permission Audit Checklist.

Object access does not equal field access. A user may have Read access to an object but field-level security controls which individual fields they can see or edit.

In practice, FLS exposure often builds up over time. A permission set may open fields that were part of a project and were never reviewed for removal. Old profiles may expose fields that were added during setup and were never locked down after go-live.

Fields that commonly carry FLS exposure risk include:

• Compensation, salary, or bonus fields
• Tax, identity, or SSN-adjacent fields
• Margin, profitability, or pricing fields
• Integration service account flags or system-only fields
• Admin-only workflow fields used in automation
• Customer, member, or vendor status fields tied to commercial terms
• Fields populated by a managed package that should not be user-editable

Field cleanup and access review should be connected. A field that appears stale or low-fill may still be exposed to more users than it should be. A field being considered for removal may have FLS patterns worth documenting before the change. For more on the field cleanup side, see the Field Cleanup Guide.

It is not enough to know a permission set exists. Admins need to know who has it, how many users are assigned, and whether those assignments still make sense.

User assignment patterns worth reviewing include:

• Users with many permission sets, especially where the cumulative access is broad
• Users with access that appears to fall outside their current role or team
• Inactive or stale users who still hold active permission set assignments
• External, community, or portal users who may have broader field or object access than intended
• Admins or power users with unusually broad system permissions
• Permission sets assigned to only one user, which may indicate orphaned or forgotten exception access
• Permission sets assigned to a large number of unrelated users, which may suggest over-broad access was used as a shortcut

Assignment patterns are signals, not conclusions. Each pattern needs business context before any change is made.

Inherited orgs amplify every permission set sprawl problem. When an admin or consultant takes over an org, they often find:

• Old profiles that were never updated when the organization restructured
• Cloned permission sets with names that do not describe what they actually grant
• Temporary access that was created during a project and was never reviewed after go-live
• No documentation explaining why specific permission sets exist or who requested them
• Users with stacked access from multiple role changes, each of which added without removing the previous
• Admins who are afraid to remove anything because they cannot trace what the access is used for
• Leadership asking for access cleanup without understanding the downstream risk

In this context, access review is not just an operational task. It is a discovery task. The first step is not cleanup. The first step is visibility.

For broader inherited org review context, see Inherited Org Checklist, Technical Debt Assessment, and Salesforce AI Readiness.

The goal of a permission review is not to remove access as quickly as possible. The goal is to understand which access exists, who has it, why it may exist, and what needs validation before changes are made.

Treating sprawl cleanup as primarily a deletion task leads to access removal without enough evidence. The safer framing is:

• Candidate for review: a permission set or assignment that warrants investigation but has not been validated
• Needs owner validation: access that cannot be explained without business context from the responsible team
• Over-privileged access signal: a pattern where access appears broader than the user's role would suggest
• Sensitive exposure signal: a field or object permission that may expose sensitive data to more users than intended
• Assignment pattern to investigate: a user assignment pattern that looks unusual but needs context before action

These are review signals, not removal instructions. A structured access review creates the evidence layer that makes deliberate, validated change possible. For more on this framing, see the Diagnostic Tool Security Checklist for context on how diagnostic tools should interact with access data.

KeelCadence Permission & FLS Audit turns Salesforce access metadata into a review-ready XLSX workbook so admins and consultants can review profiles, permission sets, object permissions, FLS exposure, and user assignment patterns before making access changes.

Permission set sprawl is not solved by deleting old permissions blindly. It is solved by making access understandable enough to review, validate, and change deliberately.

That requires a structured first-pass review: profiles, permission sets, object permissions, FLS exposure, sensitive field patterns, and user assignment context. Without that evidence layer, access review is guesswork.

KeelCadence helps teams create that first-pass access review workbook before changing permissions in a messy or inherited Salesforce org.