The Short Answer
A Health Check is an evidence-based diagnostic process lasting two to six weeks, culminating in three deliverables: a prioritized list of findings by severity, a 30-day Quick Wins plan, and a Roadmap for in-depth investments. What makes it useful isn't the breadth of the scan, but the evidence attached to each finding—a number, a log, or a screen recording—because without it, discussions devolve into debates of opinions.
Seven Examination Axes
| Axis | What's Actually Examined | Evidence Source |
|---|---|---|
| Process and Adoption | Is the documented process actually being followed? | Login History, Field Usage, User Observation |
| Data Model | Redundant Objects, Unused Fields, Duplicate Relationships | Field Usage, Metadata API, Sample Queries |
| Automations | Overlaps between Flows, Triggers, and old Process Builder | Metadata, Debug Logs, Execution Order Analysis |
| Permissions and Security | Bloated Profiles, Conflicting Sharing Rules, Excessive Access | Security Health Check, Permission Set Assignments |
| Integrations | API Limits, Recurring Failures, Error Handling | Event Monitoring, Middleware Logs |
| Performance | Loading Times, Heavy Queries, Stuck Batch Jobs | Lightning Usage App, Apex Jobs |
| Cost and Licensing | Unused Licenses, Storage, Duplicate Services | Licensing Report, Invoice vs. Actual Usage |
How Severity is Rated
Arbitrary ratings render a report useless. The method that works: each finding receives two scores between 1 and 5—Impact (what happens to the business if not addressed) and Frequency (how many times per month it occurs). The product determines priority, not an assessment of how "ugly" the code is. A finding with a score of 20 or more is addressed immediately; 12–19 is scheduled for the upcoming quarter; below 12 is noted but not addressed, unless it's cheap to fix while working on something else.
The most crucial distinction in the report is between symptom and root cause. "Users don't fill in the Reason for Loss field" is a symptom; the root cause might be that the field isn't required, the picklist values aren't relevant to the domain, or no one reviews the report based on it. Fixing only the symptom—making the field required—generates bad data instead of missing data.
What You Get in the End
A valuable deliverable includes a findings document with evidence for each line item, a severity matrix, a 30-day plan where each item can be executed without architectural changes, and a one-to-two-quarter Roadmap with rough effort estimates. Additionally, a Decision Log of three to five critical organizational decisions is required—for example, whether to merge two business units into one Org—because without them, the Roadmap is uncertain.
Further discussion on decisions following the diagnosis can be found in Rebuild vs. Refactor and Prioritizing Technical Debt.
Common Risks and Preventive Actions
The first risk is a report perceived as an accusation list. If findings are phrased as criticism of an internal team, the organization becomes defensive rather than corrective. Proper phrasing focuses on the current state and ongoing costs, not historical responsibility.
The second risk is a review that concludes without an owner. Every finding must have a person's name and a date; otherwise, the report joins a folder no one ever opens. The third risk is excessive breadth: a diagnosis attempting to cover all seven axes in full depth in two weeks will produce a superficial overview across the board. It is better to choose three axes for in-depth analysis and mark the rest for the next round.
How to Measure Success
A Health Check is successful if, within 60 days, at least 70% of the 30-day items have been completed, if management has approved a budget for at least one in-depth investment, and if two operational metrics—for example, integration failure rate or central screen loading time—have shown measurable improvement against a baseline established at the beginning of the diagnosis.
Next Steps
Before ordering a review, it's advisable to prepare three things: a list of critical business processes, read access to logs and metadata, and names of three actual users whose work can be observed. These three items shorten the diagnosis by about a week and significantly improve the quality of findings.