Salesforce orgs rarely break all at once. They degrade. A validation rule added in a hurry, a Process Builder nobody remembers, a report built on a field that no longer means what it used to. Each change is small. Five years later, releases are slow, users do not trust the data and every new requirement costs more than it should.

A Salesforce org health check stops that drift. This article gives you a practical 30-point checklist our consultants use, grouped into seven areas, followed by a simple way to prioritise what you find. You can run most of it yourself with standard Salesforce tools.

Why does a Salesforce org need a health check?

Three reasons come up in almost every review:

• Security exposure. Access tends to grow and rarely shrinks. Throughout 2025, several widely reported incidents involved attackers using stolen OAuth tokens from third-party integrations, or persuading staff to authorise malicious connected apps, to export Salesforce data. Permission and integration hygiene is no longer optional.
• Retired technology. Salesforce ended support for Workflow Rules and Process Builder at the end of 2025, and has been retiring legacy API versions. Orgs that depend on them carry growing risk.
• Wasted spend. Inactive users holding licences, unused add-ons and duplicated tools are common and easy to recover.

Signs your org needs a review now

• Deployments regularly fail on tests or take days to validate
• Users export data to spreadsheets because they do not trust reports
• Nobody can explain what happens when an Opportunity is closed
• You see "Apex CPU time limit exceeded" or "Too many SOQL queries" errors
• You are planning a new cloud, a data migration or an AI agent project
• Your original implementation partner or admin has left

The 30-point Salesforce org health check checklist

Security and access (1–7)

1. Security Health Check score. Open Security Health Check in Setup, review high-risk settings against the Salesforce baseline and record the score.
2. Multi-factor authentication. Confirm MFA is enforced for all direct logins, including admins and integration users that log in interactively.
3. System Administrator count. List everyone with the System Administrator profile or "Modify All Data". Most orgs need far fewer than they have.
4. Profiles versus permission sets. Check whether access is managed with permission sets and permission set groups, as Salesforce recommends, or through a sprawl of cloned profiles.
5. Connected apps and OAuth tokens. Review every connected app, who can authorise it, its scopes and active tokens. Remove anything unused.
6. Integration users. Ensure each integration has a dedicated, least-privilege user rather than a named person’s login.
7. Guest and community user access. Verify guest user sharing, object permissions and exposed Apex classes on public sites. See our guide to Salesforce security and access control for the fundamentals.

Data quality and storage (8–12)

8. Duplicate records. Check matching and duplicate rules on Leads, Contacts and Accounts, and measure the duplicate rate with a sample report.
9. Required data completeness. Measure how often key fields such as industry, lead source or close date are blank or defaulted.
10. Unused custom fields. Use "Where is this used?" and field population reports to find fields nobody fills in or references.
11. Storage consumption. Review data and file storage in Company Information, and identify old attachments, logs or email records that can be archived.
12. Record ownership. Find records owned by inactive users or generic queues that should have real owners. Our article on Salesforce data management covers the practices behind this.

Automation (13–18)

13. Workflow Rules and Process Builder inventory. List every active one and plan migration to Flow using the Migrate to Flow tool where it fits.
14. Automation per object. For your busiest objects, map every trigger, Flow, validation rule and legacy automation. Overlapping automation causes unpredictable results.
15. Flow error emails. Check who receives Flow and Apex error emails, and whether anyone reads them.
16. Record-triggered Flow design. Look for Flows with DML or queries inside loops, and before-save Flows that could replace after-save updates.
17. Scheduled jobs. Review scheduled Apex and scheduled Flows, their owners and whether they still serve a purpose.
18. Hard-coded values. Search for hard-coded record IDs, user names or email addresses in Flows and formulas. Move them to custom metadata. Our overview of automation in Salesforce explains the options.

Code and customisation (19–23)

19. Test health. Run all local tests. Record failures, overall coverage and classes below 75%.
20. Test quality. Sample test classes for assertions, bulk scenarios and use of SeeAllData=true.
21. Static analysis. Run Salesforce Code Analyzer and review security and performance violations such as SOQL in loops or missing access checks.
22. Trigger architecture. Check for multiple triggers per object and logic written directly in triggers rather than handler classes.
23. Unused components. Identify Visualforce pages, Aura components, Apex classes and installed packages that are no longer used.

Integrations and platform limits (24–27)

24. API usage. Review daily API request consumption and which integrations drive it.
25. Legacy API versions. Check integrations and code for very old API versions and upgrade them before they are retired.
26. Error handling. Confirm each integration logs failures somewhere a person monitors, with a retry approach.
27. Governor limit near-misses. Review debug logs or monitoring for transactions close to CPU, SOQL or heap limits during peak loads.

Adoption and licences (28–30)

28. Login and usage. Report on users who have not logged in for 60 or 90 days, and reclaim or reassign their licences.
29. Report and dashboard hygiene. Count reports not run in a year and dashboards with no viewers. Archive them so users find the ones that matter. See reports and dashboards in Salesforce.
30. User feedback. Interview five users per team: what they avoid, what they re-key and what they export. This finds the problems no tool will.

How to prioritise what you find

A health check typically produces dozens of findings. Score each one on impact and effort, then work in this order:

A 30-60-90 day plan after the health check

1. First 30 days: close security risks, remove unnecessary admin access, review connected apps, reclaim unused licences and fix failing tests.
2. Days 31–60: migrate the highest-risk Workflow Rules and Process Builders to Flow, consolidate automation on your busiest objects and clean the top data quality issues.
3. Days 61–90: introduce governance practices such as a change approval process, source control and release notes, then schedule the next review.

DIY or partner-led health check?

An internal admin can complete many checklist items, especially adoption, reports and licences. A partner adds value where objectivity and depth matter: security architecture, code quality, integration risk and a realistic remediation plan. A partner-led review is also sensible before large investments, because the findings directly shape the cost and scope of your next project, and before launching AI agents with Agentforce, which depend on clean data and reliable automation.

Get a Salesforce org health check from Groviya

Groviya’s certified consultants review your org against this checklist and more, interview your users and deliver a prioritised report with effort estimates and a 90-day roadmap. If you prefer, we can then fix the findings with you. Learn about our Salesforce support and implementation services or request a health check.