Every Salesforce org accumulates permission sets the same way it accumulates custom fields: one per project, rarely removed. A consultant needs access for three months. A new integration requires API permissions. A specific user gets their own permission set because the admin doesn't want to touch the standard profile. Three years later, the org has 87 permission sets and nobody knows what half of them are for.
The security risk isn't always obvious. A permission set from 2021 that granted access to a sensitive object, created for a consultant engagement that ended in early 2022, may still be assigned to users who were onboarded during that project. The consultant left. The admin who created the permission set left. Nobody revoked anything.
This guide covers how to audit your permission set inventory, identify orphaned and over-permissioned assignments, and build a cleanup process that doesn't break anything in production.
Why Permission Sets Accumulate Unchecked
Permission sets are easy to create and easy to forget. Unlike profiles — which are structural and tied to user types — permission sets are project-level. They're meant to be temporary. But there's no native mechanism that flags permission sets as candidates for retirement once their associated project ends.
The pattern that creates orphaned permission sets:
- Consultant engagement: A contractor needs specific access for a 3-month project. Admin creates a permission set named Consultant_Integration_2021, assigns it, and the project ends. Nobody removes the permission set when the consultant's access is revoked.
- Proof-of-concept integrations: A new tool is evaluated. A permission set is created with API access to test it. The tool isn't purchased. The permission set remains, still assigned to the admin who tested it.
- User-specific access grants: "This one person needs access to this one object." A permission set gets created for one user. The user changes roles 18 months later. The permission set stays.
- Test environments migrated to production: Configuration created in a sandbox to test a new feature is copied to production with the same permission sets. The sandbox gets deleted. The production permission sets remain.
The damage depends on what those permission sets grant. A permission set that grants Read access to a standard object is a minor hygiene problem. A permission set that grants Create/Edit/Delete on a custom object containing customer financial data is a serious security gap.
What "low assignment" actually means
A permission set with fewer than 5 assigned users isn't necessarily orphaned — it might be a legitimate small-group permission. The distinction matters: a permission set named Finance_APAccess assigned to 3 finance users is intentional. A permission set named proj_Q2_integration assigned to 3 users from a 2021 project is not.
The naming convention is the first signal. Second signal is the last-modified date on the permission set itself. Third signal is the creation date relative to the assignment date — if users were assigned after the permission set was created, that's normal. If the permission set was created and then never touched again, that's a different profile.
The Permission Audit Process
A permission set audit has four phases. Running them in order catches the most risk in the least time.
Phase 1: Inventory — what do you actually have?
Most admins know roughly how many permission sets their org has. Few know exactly which ones exist, who created them, and when they were last modified. Start here.
In Setup, navigate to Users → Permission Sets. Export the list. Fields to capture:
- Permission Set Label and API Name
- Created Date
- Last Modified Date
- Assigned Users count
- Which user licenses it requires
Then run an assignment report: Reports → New Report → Users → Permission Set Assignments. This gives you the full assignment matrix — every permission set, every assigned user. Sort by assignment count descending. The bottom of that list is where the orphaned permission sets hide.
Phase 2: Risk scoring — which permission sets are dangerous?
Not all orphaned permission sets are equal risk. Score each candidate across two dimensions: sensitivity of what it grants, and confidence it is no longer needed.
High-risk permission sets to look for immediately:
- Permission sets that grant Modify All or Delete on custom objects
- Permission sets that grant API access (API Enabled, Manage API)
- Permission sets that grant View All or Edit All on standard objects containing sensitive data
- Permission sets that include Manage Users or View Setup and Configuration
- Permission sets created more than 24 months ago and never modified since
For each high-risk candidate, check: who has this? Are those users active? Do they have a documented reason to have this access? If the answer to any of those questions is "I don't know," that's the gap.
The "I don't know" problem
The most common outcome of a permission set audit is finding access assignments where the admin can't explain why they exist. The user who has the permission set was hired in 2021. The permission set was created in 2021. Nobody remembers the connection, and there's no internal ticket that documents it.
The remediation isn't a simple revoke. You need to contact the user, confirm whether they need the access, and get a business justification on record before removing it — otherwise you're the admin who revoked someone's access and can't explain why.
Build a 2-week review window into your cleanup process. Email affected users: "We are conducting a security review of permission sets. You are currently assigned to [X]. Do you use this access in your day-to-day work?" If no response in 2 weeks, escalate to their manager.
Run Your Permission Set Audit Now
The Permission Auditor inventories your permission sets, flags low-assignment and over-privileged assignments, and exports a cleanup priority list — no Salesforce credentials required to start.
Phase 3: Conflict detection — which assignments contradict each other?
Permission sets can conflict in ways that aren't immediately obvious. A user might have two permission sets that together grant more access than either intended:
- Cumulative object access: Permission Set A grants Read on Account. Permission Set B grants Edit on Account. The user has Edit via B — but if B also grants Delete on Account, they now have Delete and nobody approved Delete.
- Field-level access conflicts: One permission set grants Edit on a custom field. Another permission set removes Edit on the same field (using field-level security). The outcome depends on the order the permission sets were assigned — Salesforce applies field-level restrictions last, which is the logical behavior, but it's hard to reason about when auditing a permission set matrix.
- System permissions stacking: Two permission sets each grant one piece of a sensitive system permission (like "Manage Salesforce CRM Content" split across multiple permission sets to make each one look less privileged).
The Permission Auditor maps the effective access across all permission set assignments for each user, so you can see what a user actually has when all their permission sets are combined — not just what each individual permission set grants in isolation.
Phase 4: Dependency checking — what breaks if I revoke this?
Before revoking any permission set, check for dependencies. A permission set that looks orphaned might still be required for an active integration.
Common active dependencies:
- Connected Apps: A Connected App may require a specific permission set for OAuth. Removing that permission set breaks the integration silently.
- API integrations: A service account needs API Enabled. Removing the permission set stops the integration.
- Scheduled jobs: A user account running scheduled Apex or Flow that has elevated permissions needs those permissions to succeed.
- Delegated authentication: Some orgs delegate authentication to an external identity provider, which assigns permission sets via the delegated auth rules.
Check Connected Apps in Setup first: Apps → App Manager → [App] → View → Policies → Session Settings. This shows what permission sets the app requires. Then check active Apex jobs: Settings → Monitoring → Apex Jobs. Filter by the user whose permission set you're considering revoking.
Redundant Permission Sets: When to Merge
After cleanup, you may find you have multiple permission sets that serve the same purpose. Two permission sets that both grant Read/Edit on the same 12 objects and nothing else is unnecessary complexity.
Merge when:
- Two or more permission sets serve the same team (e.g., Sales_Mobile_Access and Sales_CRM_Access for the same group of users)
- One permission set is a subset of another and the subset provides no isolated benefit
- A permission set was created as a workaround for a limitation that's since been resolved (e.g., before permission set groups existed)
Don't merge when:
- Different teams need the same permissions but should be managed separately for audit purposes
- One permission set is environment-specific (Production vs Sandbox access)
- The permission set is tied to an external compliance requirement that audits access at the permission set level
Permission Cleanup Is Part of a Larger Audit
Orphaned permission sets are one piece of configuration debt. Run the full suite to find validation rule conflicts, unused fields, and Flow health issues alongside permission hygiene.
The Permission Cleanup Playbook
Once you've completed the audit and dependency check, here's the sequence to close the gap safely:
- Export the current assignment matrix. This is your rollback plan. If something breaks, you can reassign exactly what was there.
- Build a review list. Every permission set with ≤5 assigned users that was created more than 18 months ago and hasn't been modified in 12 months goes on the review list. High-sensitivity permissions go to the top.
- Send the user notification. Email affected users directly. Don't use a mass template — reference their specific permission set by name. Ask them to confirm whether they need it within 10 business days.
- After the review window, revoke unconfirmed assignments. Use the Permission Set Assignment report to bulk-revoke via Data Loader or the UI. Update the assignment matrix.
- Deprecate the permission set. Remove all assignments, then deactivate it (or delete if you're confident nothing references it).
- Document in CLAUDE.md that the permission set was retired and why. This is the institutional knowledge that prevents the next admin from recreating it.
Do this quarterly. Permission set accumulation is continuous — if you run this process once and never look again, you'll be back to the same position in 18 months.
Preventing future accumulation
Permission set hygiene is a process problem, not a one-time cleanup. Build the following into your onboarding:
- Every permission set created must have a business justification and an owner in the description field
- Every permission set must have an expiration date or review trigger (e.g., "Review before March 2027")
- When a project or engagement ends, the admin must review and remove all project-specific permission set assignments as part of project close-out
- Quarterly permission set review is on the admin's recurring task list — calendar it
- Connect all Connected Apps to an owner who is notified when the app's permission requirements change
What This Has to Do with AI and Agentforce
Salesforce's Agentforce and Einstein features read your org's permission structure to determine what an AI agent can and cannot do. The AI inherits the permission context of the user it's acting on behalf of.
If that user has 4 permission sets — 3 intentional and 1 orphaned from a 2021 integration — the AI agent has access to whatever that orphaned permission set grants. The AI doesn't know the difference between intentional and orphaned. It just operates within the permission envelope it's given.
Cleaning up permission sets isn't just a security hygiene practice in 2026. It's prerequisite work for safe AI adoption on Salesforce. Every orphaned permission set is a potential unintended AI capability sitting in your org, waiting for the next user or agent that inherits it.
Related: Salesforce Admin Debt: What It Costs and How to Fix It — how permission set accumulation fits the broader pattern of configuration debt across your org.
Get Your Full Permission and Configuration Audit
Free tools. No Salesforce credentials required for the initial scan. Founding Member plan: $79/month per org, 14-day free trial, no credit card required.