Over-permissioned users are a silent security risk in Salesforce. I've seen them cause data leaks in healthcare orgs (exposing patient records) and compliance failures in financial services. The fix starts with identifying them—before an auditor or breach hits. Here’s how to do it practically, based on 10+ enterprise deployments.
Why This Matters: Real Consequences
In a recent healthcare client, a sales rep had "System Administrator" permissions. They accidentally deleted a critical patient data object during a demo. The audit trail showed they accessed PHI via the "Marketing User" profile, which was incorrectly granted. Regulatory fines followed. Over-permissioning isn’t theoretical—it’s a compliance time bomb.
Step 1: Target High-Risk Profiles First
Don’t scan all users. Focus on profiles with excessive permissions:
System Administrator: Only 2-5 people should ever have this. In a manufacturing client, 12 users had it—4 were contractors who left the org 6 months prior.
Custom "Super User" Profiles: I found a "Finance Super User" profile in a retail org with full object access, including "Campaign Member" (irrelevant for finance). It was created by a dev who didn’t understand permission sets.
Step 2: Run Targeted SOQL Queries
Use these queries in Developer Console (adjust as needed for your org). Start with the most dangerous profiles:
SELECT Id, Name, Profile.Name
FROM User
WHERE Profile.Name IN ('System Administrator', 'Finance Super User', 'Custom Admin')
AND IsActive = true
Now, drill into object-level access. This query finds users with "Read/Write" on sensitive objects (like Account or Opportunity) beyond their role:
SELECT User.Name, User.Profile.Name, ObjectPermissions.SobjectType, ObjectPermissions.Allowed
FROM ObjectPermissions
WHERE SobjectType IN ('Account', 'Opportunity', 'Contact')
AND Allowed = true
AND (PermissionType = 'Read' OR PermissionType = 'Edit')
AND NOT User.Profile.Name IN ('Standard User', 'Sales User')
Step 3: Check Permission Sets (The Hidden Culprit)
Permission sets often grant excessive access without admins noticing. In a financial services org, a "Loan Officer" permission set had "Create" on Account and Opportunity—but loan officers shouldn’t create accounts. They’d accidentally merge accounts during lead assignment.
To find overused permission sets:
SELECT PermissionSet.Name, COUNT(UserId)
FROM PermissionSetAssignment
GROUP BY PermissionSet.Name
HAVING COUNT(UserId) > 20
Sort results by count. If a set like "Full Access to CRM" has 50+ users, audit it immediately.
Step 4: Validate with User Activity
Permissions mean nothing if unused. Run this to find inactive users with high access:
SELECT Name, Profile.Name, LastLoginDate
FROM User
WHERE LastLoginDate In one org, 7 "System Admin" users hadn’t logged in for 2 years. We revoked their access during the next audit cycle.
### Final Tip: Automate the Scan
Manual checks miss risks. I built a simple Apex script that runs weekly, flags users with >3 "Custom" profiles or access to >5 sensitive objects, and emails the admin team. It caught a contractor’s access to `Case` records in a 10k-user org that persisted for 18 months.
Don’t wait for the breach. Over-permissioned users are the #1 vector for Salesforce data exposure. If you’re not scanning for them quarterly, your org is vulnerable.
Stop guessing. Run a free, automated health scan to find every over-permissioned user in your org—before compliance fails. [Get your free Salesforce security scan now](https://orgscanner.dev).
**📚 Recommended Resource:** [Salesforce for Dummies](https://www.amazon.com/dp/1119576326?tag=onamznic0b710-20) — great for anyone learning Salesforce.
**📚 Recommended Resource:** [NIST Cybersecurity Framework Guide](https://www.amazon.com/dp/1119892457?tag=onamznic0b710-20) — great for anyone security frameworks.
---
*Need a second opinion on your Salesforce org? [Request a diagnostic](https://orgdoc.dev/start).*
Top comments (0)