Salesforce Org Health Check Checklist
A structured checklist for reviewing the health of a Salesforce org, covering access, automation, code, data and limits, with sample SOQL queries for the first checks.
Salesforce orgs accumulate decisions. Ten admins, three partners and several years later, nobody is sure which flows still matter, who can see what, or why a save takes four seconds. An org health check is a deliberate pause to find out, before the next project builds on top of the problems.
This checklist is the structure we use as a starting point. It works for a self-review by an internal admin team or as preparation for an external review.
Before you start
- Work in a recently refreshed full or partial copy sandbox where possible, and use production only for read-only checks.
- Run Salesforce's built-in Health Check in Setup for a baseline of security settings, and the Optimizer report if it is available in your org.
- Agree who will receive the findings and who can approve fixes. A health check without an owner becomes a document, not a change.
What to check, area by area
| What to look for | Why it matters | |
|---|---|---|
| Users and licences | Active users who have not logged in recently, shared logins, integration users with full licences | Security exposure and wasted licence cost |
| Permissions | Profiles or permission sets with Modify All Data, View All Data or Author Apex assigned to many users | Least privilege is the strongest control you have |
| Sharing model | Organisation-wide defaults, sharing rules and manual shares that no longer match the business | Data visibility errors and slow recalculations |
| Automation | Overlapping flows, legacy Workflow Rules and Process Builder still active, triggers without a framework | Unpredictable order of execution and errors on save |
| Apex and LWC | Low or synthetic test coverage, SOQL in loops, hard-coded IDs, unused classes | Deployment failures and governor limit errors |
| Data quality | Duplicate accounts and contacts, empty required-in-practice fields, inconsistent picklists | Poor reporting and failed integrations |
| Data volume | Very large objects, large data skew on single owners or parents, storage use | Performance, locking and storage cost |
| Integrations | Integration users, connected apps, Named Credentials, error logs and API usage trends | Silent failures and limit exhaustion |
| Technical debt | Unused fields, reports, page layouts, record types and managed packages | Slower change and confused users |
Starter queries
These SOQL queries can be run in the Developer Console query editor or with the Salesforce CLI. They are starting points; adjust the time windows to your own policy. Treat the results as leads to investigate, not as a list of things to delete.
SELECT Id, Name, Username, Profile.Name, LastLoginDate
FROM User
WHERE IsActive = true
AND (LastLoginDate < LAST_N_DAYS:90 OR LastLoginDate = null)
ORDER BY LastLoginDate ASC NULLS FIRSTSELECT Assignee.Name, Assignee.Username, PermissionSet.Name,
PermissionSet.IsOwnedByProfile, PermissionSet.Profile.Name
FROM PermissionSetAssignment
WHERE Assignee.IsActive = true
AND PermissionSet.PermissionsModifyAllData = trueRunning the check
- 01
Gather context
Collect the list of business processes, integrations and recent incidents. Findings only make sense against how the org is actually used.
- 02
Run the automated tools
Use Health Check, Optimizer where available, and static analysis on Apex and LWC to produce a baseline quickly.
- 03
Review each area
Work through the table above, recording each finding with evidence, affected users or processes, and a severity.
- 04
Rate and group findings
Separate urgent security or data risks from performance issues and from clean-up work. Group related findings so fixes can be planned together.
- 05
Agree a remediation plan
Give each group an owner, an effort estimate and a target release. Quick, low-risk wins can go first.
- 06
Re-check after fixes
Repeat the relevant queries and tool runs to confirm the change worked and nothing regressed.
Reading the results
- Security findings come first. Excessive permissions and stale active users are cheap to fix and carry the most risk.
- Automation overlap is the usual cause of "random" errors. If several flows, triggers and legacy rules act on one object, map them before changing any. Salesforce recommends moving Workflow Rules and Process Builder to Flow; check current retirement guidance in Salesforce Help. See record-triggered flow best practices.
- Code issues show up as limits. SOQL or DML inside loops is the commonest cause of governor limit errors under load; bulkifying Apex triggers explains the fix.
- Clean-up needs care. Before deleting a field, check reports, flows, Apex, integrations and Marketing Cloud Connect sync settings that may reference it.
If your org also feeds Marketing Cloud, the Marketing Cloud audit is the matching review on the marketing side.
Want an independent view of your org?
GeekMidst runs structured org health checks and turns the findings into a prioritised plan your team can act on.
