A Salesforce health check reviews six areas of an org: who can access what, whether the data can be trusted, how automation behaves, how much unused or unsupported build has piled up, whether people actually use the system, and how close the org runs to platform limits. Each finding gets a risk rating and an effort estimate, so the result is a ranked work list rather than a long inventory. Most orgs need one after an admin change, before a major project, or every year or two.
The six areas at a glance
Treat the checklist as a set of questions to answer with evidence from the org, not a form to tick. The table below shows what each area covers, why it earns a place in the review, and the kind of finding that tends to surface there.
| Area | What to review | Why it matters | A typical finding |
|---|---|---|---|
| Security and access | Admin users, MFA, profiles, permission sets, sharing, integration users, connected apps | Access problems are the costliest to discover late | Former staff or vendors still holding System Administrator |
| Data quality | Completeness of key fields, duplicates, stale records, picklist hygiene, record ownership | Reports, automation and AI all repeat what the data says | Accounts owned by inactive users, so nobody follows up |
| Automation | Flows, Apex triggers, remaining Workflow Rules and Process Builder, scheduled jobs, error emails | Overlapping automation causes slow saves and silent failures | Two automations updating the same field in different orders |
| Technical debt | Unused fields, objects, page layouts, reports, Apex classes and installed packages | Clutter slows every future change and confuses users | Hundreds of fields with no values and no references |
| Adoption | Login frequency, record creation by team, report and dashboard usage, workarounds | An unused system has no return, however well it is built | A team logging in weekly and keeping its pipeline in a spreadsheet |
| Limits and storage | Data and file storage, API calls, email sends, custom object and field counts | Hitting a limit stops work for everyone at once | An integration consuming most of the daily API allocation |
Security and access: start with who can do what
Begin by listing every active user with System Administrator or an equivalent permission such as Modify All Data, and ask who approved each one. Then confirm that multi-factor authentication covers every direct login, that integrations run as dedicated users rather than a person's account, and that nobody outside the company still has a working login.
Salesforce's built-in Health Check page, under Setup, scores your security settings against the Salesforce Baseline Standard and groups them as high, medium and low risk. It is a fast first pass for password, session and login settings, but it does not look at who holds which permissions or how records are shared. Our Salesforce security review checklist covers those deeper questions.
Data quality: measure the objects that drive decisions
Pick the four or five objects the business runs on, usually accounts, contacts, leads, opportunities and cases, and measure them rather than sampling by eye. For each one, record:
- The share of records missing each field that a report, dashboard or automation depends on.
- Duplicate counts using simple keys such as email address, website domain or a normalized name.
- Records owned by inactive users or by a generic admin account.
- Open opportunities with close dates in the past, and cases untouched for months.
- Picklist fields with values nobody has chosen in a year, or free-text fields standing in for picklists.
- Whether duplicate and matching rules exist, and whether they block, alert or do nothing.
These numbers become the baseline. When the fixes are done, run the same queries again so improvement is shown, not asserted.
Automation and technical debt
List every active automation on each object, including record-triggered Flows, Apex triggers and any remaining Workflow Rules or Process Builder processes. Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025. Existing automation keeps running, but bugs will no longer be fixed, so each one still active is a finding with a migration path through the Migrate to Flow tool.
Look for more than one automation writing to the same field, Flows that fail without anyone receiving the error email, and scheduled jobs running as users who have left. On the technical-debt side, find fields with no data and no references, Apex classes nothing calls, unused page layouts and record types, and installed packages nobody can explain. Salesforce Optimizer, the old built-in report for much of this, was retired in Winter '26; Salesforce's admin team now points to Org Check, a free Salesforce Labs app, for the same kind of metadata analysis.
Adoption and platform limits
Adoption is measured, not surveyed. Compare last-login dates against the people who should be using the org, count records created per team per week, and check which dashboards anyone opens. Then ask the users directly what they keep outside Salesforce. The answer usually points to a missing field, a slow page or a report they do not trust.
For limits, open the System Overview page in Setup. It shows data storage, custom object counts and API requests in the last 24 hours, and flags usage near the limit. API limits apply to the whole org, so one noisy integration can block every other integration until the 24-hour total drops. Check file storage and email limits too: a staffing company we worked with found its reps hitting Salesforce email limits, alongside dashboards that mixed every rep's activity together.
Close the adoption review with licenses. Set the number of active users on each license type against the number your contract pays for, and list users who have not logged in for 90 days. Frozen accounts still consume a license, and add-on products that were bought but never configured belong on the findings list, since they cost money every renewal without returning anything.
How to prioritize what you find
Every finding gets two ratings: risk, meaning what happens if it is left alone, and effort, meaning roughly how long the fix takes. Then sort into four groups.
- Fix now: high risk, low effort. Removing stale admin access, turning on MFA gaps and moving an integration off a personal login usually belong here.
- Plan next: high risk, higher effort. Migrating legacy automation, redesigning a sharing model or cleaning a key object needs a scoped project.
- Batch together: low risk, low effort. Deleting unused fields and reports is best done in one tidy-up pass with a backup.
- Park with a reason: low risk, high effort. Write down why it is parked so the next review does not rediscover it as new.
Weight risk toward anything touching security, money or customer data, and toward anything a planned project will depend on. If Agentforce or a new integration is on the roadmap, data quality and permissions findings on the objects it will use move up the list. A useful output fits on one page: the top ten findings, an owner for each, and the date the checks will run again.
