A Salesforce org that was well configured at implementation tends to drift over time. Business processes change. Users leave and take undocumented knowledge with them. Quick-fix automation accumulates. Data quality declines. By the time someone decides to run a health check, the org has often developed significant technical debt that is silently affecting performance, reliability, and user trust.
A proper health check identifies what's working, what's broken, and what's creating risk — before those issues become expensive problems. Here's what it covers.
Data quality
Data quality is usually the first area flagged and the one with the most immediate business impact. Common issues:
- Duplicate records: Accounts, Contacts, and Leads duplicated from imports, integrations, or manual entry. Check using the Duplicate Management tools and review the org's deduplication rules (if any).
- Missing required data: Records with key fields blank — no email on Contact, no Account on Contact, no Close Date on Opportunity. Review validation rules and whether they are consistently enforced.
- Stale data: Opportunities that haven't been updated in months, Leads with no activity, accounts with no associated contacts. Identify records that are cluttering reports but contain no useful information.
- Inconsistent picklist values: Custom picklist fields populated with free text to bypass validation, or values that no longer match current business terminology.
Security and access model
Access configuration is one of the highest-risk areas in any Salesforce org. Issues found here can represent compliance risk, data exposure, or access that far exceeds what users need for their job.
- Excessive Profile permissions: Standard Users with Modify All Data, View All Data, or API Enabled. These permissions should be granted only to specific roles that genuinely need them.
- Inactive users still active: Users who have left the company and not been deactivated. Every active user represents a potential access vector. Review all active users against current staff.
- Sharing rules overexposed: OWD set to Public Read/Write on objects that should be private. Or sharing rules that effectively give everyone access to everything.
- Permission Set proliferation: Dozens of overlapping Permission Sets with no clear ownership or documentation. Review which are actively assigned and which can be consolidated.
Automation health
Legacy automation — Workflow Rules, Process Builders — should be flagged for migration to Flow. Salesforce has retired Process Builder and is actively deprecating Workflow Rules. Orgs still running these tools are carrying automation that will need to be rebuilt on a timeline set by Salesforce, not by the business.
- List all active Workflow Rules, Process Builders, and Flows. Identify which are still business-relevant and which are obsolete.
- Check for automation conflicts — multiple automation types on the same object that could fire in unintended sequences.
- Review scheduled Flows for Flows that are no longer needed but still running.
- Check for Flows with errors — the Flow Error Email goes to a specified admin email. If that email is unmonitored, errors are silently accumulating.
Apex code quality
If the org has Apex triggers or classes, the health check should include a code review:
- Test coverage: Is the org above 75%? Is coverage meaningful (assertions present) or just coverage-padding?
- Bulkification: Are there triggers with SOQL or DML inside loops? These are governor limit failures waiting for production volume to trigger them.
- Multiple triggers per object: A significant risk — execution order is not guaranteed.
- Scheduled jobs: Review all scheduled Apex. Jobs no longer needed but still running consume resources and can cause confusion if they produce unexpected DML.
Integration review
External integrations with Salesforce are often the least-documented part of an org. The health check should identify every system connected to Salesforce — including Connected Apps, Named Credentials, and any integration middleware — and verify that:
- Integration users are using dedicated service accounts, not named employees (who can leave).
- Integration credentials have been rotated recently and are properly secured.
- API usage is within limits and no integration is driving unexpected DML volume.
- There is documented ownership for each integration — someone who knows what it does and how to troubleshoot it.
Reports and dashboards
Report and dashboard sprawl is common in orgs over two years old. A health check typically finds:
- Hundreds of reports in a single unfiled folder, most not accessed in months.
- Dashboard components pointing to reports that have been deleted or significantly changed.
- Scheduled report emails going to email addresses that no longer exist.
- No ownership documented on critical business reports — if the person who built them leaves, nobody knows what they were for.
What comes out of a health check
A health check produces a prioritised list of findings. Not everything found needs to be fixed immediately — the output should be categorised by risk: critical (security or data integrity), high (performance or reliability), and low (governance and housekeeping).
The value of doing this regularly — annually for most orgs, more frequently for high-growth businesses — is that issues are caught while they are still small. The cost of fixing a data quality problem with 10,000 duplicate records is significantly higher than addressing it when there are 500.