To find over-permissioned users in Salesforce, list who holds the powerful permissions (View All Data, Modify All Data, Manage Users, Export Reports), who has not logged in recently, and whose access comes from old or cloned profiles. Then compare each person's access to what their job needs. A Salesforce user access review like this can be done by an admin in an afternoon with Setup and a few SOQL queries.
This guide walks through the review in order. It uses record Ids and counts, not people's names, so you can run it safely and share the results.
Why over-permissioning builds up
Nobody sets out to over-permission an org. It happens in small steps. A new hire needs to "just see" a report, so they get a bigger profile. A coordinator covers for a colleague on leave and keeps the access. A consultant clones the System Administrator profile for a project and nobody removes it.
For nonprofits and healthcare organizations this matters because the same org often holds donor details, case notes and health information. Our guide on Salesforce permissions and PHI explains why a few permissions can bypass your sharing rules entirely.
Step 1: Count your active users by profile
Start with the big picture. In the Developer Console or Workbench query editor, or any SOQL tool, run:
SELECT ProfileId, COUNT(Id) FROM User WHERE IsActive = true GROUP BY ProfileId
Then open Setup, search Profiles in Quick Find, and match each ProfileId to its profile. Flag two things: profiles with a surprising number of users, and any profile that looks cloned from System Administrator.
Step 2: Find who has the powerful permissions
These system permissions skip normal sharing and are the first thing to check.
- View All Data
- Modify All Data
- Manage Users
- Export Reports
- Customize Application
- Author Apex
The PermissionSet object has a boolean field for each system permission, and profiles have a matching permission set behind them. Salesforce documents this in its PermissionSet object reference. To see every active user with Modify All Data, whether through a profile or a permission set:
SELECT AssigneeId, PermissionSet.IsOwnedByProfile, PermissionSetGroupId
FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsModifyAllData = true
AND Assignee.IsActive = true
Change the field name to PermissionsViewAllData, PermissionsManageUsers or PermissionsExportReport to check the others. IsOwnedByProfile = true means the access comes through the user's profile. Salesforce notes that because profiles have their own permission sets, PermissionSetAssignment is the object to use to see access from profiles and permission sets together. Querying PermissionSet requires admin-level rights, and permission set groups can make results look different, so run it in a sandbox first and check a few results by hand.
Count the Ids returned. For most organizations the right number of people with Modify All Data is one or two.
Step 3: Find users who may not need access at all
Unused accounts are risky because nobody is watching them.
SELECT COUNT() FROM User WHERE IsActive = true AND LastLoginDate < LAST_N_DAYS:90
Run a second query with LastLoginDate = null for accounts that never logged in. Choose a threshold that fits your team. Seasonal volunteers and board members may log in rarely and still be legitimate, so treat the list as questions to ask, not a deactivation list.
For each Id, ask the user's manager whether the person still needs Salesforce. If not, follow your offboarding checklist.
Step 4: Review the permission sets themselves
Open Setup, search Permission Sets, and look for:
- Permission sets with vague names such as "Extra Access" or "Temp"
- Sets with a long list of system permissions
- Sets assigned to many users but built for one person
- Sets that nobody is assigned to
Open a set and choose Manage Assignments to see who has it. If you use permission set groups, review the groups too, since a group can quietly include a powerful set.
Two features help here. Salesforce supports assignment expiration on permission sets and groups, which suits temporary access. Muting permission sets let you remove a single permission from a group without rebuilding it. If you are still leaning heavily on profiles, see permission sets vs profiles.
Step 5: Check sharing-sensitive objects and fields
System permissions are not the only risk. Also check:
- Object permissions: who has View All or Modify All on sensitive objects such as cases, care plans or donations.
- Field-level security: who can read fields like diagnosis, income or government IDs.
- Integration and API users: accounts used by tools like forms or middleware often have broad access and long-lived credentials.
- Guest and community users: confirm they only reach what they should.
Step 6: Decide, document and fix
Build a simple table with one row per Id:
| Column | Example content |
|---|---|
| User Id | The 005 Id |
| Permission found | Modify All Data via profile |
| Business reason | Admin / none known |
| Decision | Keep, reduce, remove |
| Owner and date | Who approved and when |
Make changes in small steps. Remove one permission, ask the person to test their normal tasks, and move on. Keep the table, because auditors and funders often ask for evidence that you review access regularly. Our SOC 2 checklist for Salesforce covers what that evidence should look like.
Make it a habit
A one-off review fades fast. Pick a schedule, such as quarterly, and rerun the same queries. Add a rule that any new permission set with a system permission needs a second person's approval.
Doing this by hand is where many teams stall. Troppus's Apex Security Check is a Salesforce-native product built to analyze access risk, find over-permissioning and give audit-ready visibility, so the review does not depend on someone remembering to run queries.
Frequently asked questions
What counts as over-permissioned?
A user has more access than their current job needs. The test is the job, not seniority. Directors and executives are often over-permissioned because it was easier to say yes.
How often should we run a Salesforce user access review?
Quarterly is a common choice, plus a review whenever someone changes role or leaves. Choose a rhythm you will actually keep.
Can I run these queries without the Developer Console?
Yes. Any tool that runs SOQL works, such as Workbench or the Salesforce CLI. You need permission to view setup data.
Does removing a permission break reports and automations?
It can. Reports run with the viewer's access, and some automations run as a specific user. Test in a sandbox and make changes one at a time.
Should I look at names to decide who to keep?
Work from Ids and roles in the first pass, and bring the list to managers who know the people. It keeps personal details out of spreadsheets and chat.
Get a clear picture of who can see what
If you want a second opinion on your access, book a free Salesforce health check. We will review your highest-risk permissions with you and give you a prioritized list of fixes.