Many org reviews end as a report nobody acts on, and six months later the same problems return as a production incident. A review worth paying for does something narrower: it finds the decisions that will cause failures at the next step (a second cloud, a migration, an acquisition) and ranks them so someone can act. This checklist is for the sponsor who commissions the review and has to read the result.
Thresholds are not decisions
Health check tools measure thresholds: API limits, storage, inactive users who still hold admin rights. Those findings matter and are usually cheap to fix. They do not show the design choices that only hurt under load: every new feature added to Account because the data already lives there, automation built by different teams with no shared design, integrations nobody can explain.
An org can pass every threshold and still be one project away from trouble. So the review reads the configuration and also interviews the people who changed it: who decided, when, and why. For automation, ask for a dependency map (what each Flow, trigger and integration reads, writes and calls) rather than a count. A handful of entangled Flows can be harder to change than many independent ones.
Five areas to read
1. Data model
Look at relationships and cardinality, field growth on core objects (Account, Contact, Opportunity), custom objects that duplicate standard ones, such as a custom Contract next to the standard Contract, and whether the model reflects the business or the history of past projects.
The failure mode is object overloading. When Account carries fields from Sales, Service, Finance and Marketing with no separation, you get tangled permissions, ambiguous reports and automation conflicts, and the fix becomes a data migration rather than a configuration change. Also check that objects used in integrations carry external ID fields. An integration keyed on Salesforce record IDs breaks as soon as the data is reloaded or moved to another org.
2. Automation
If Process Builder or Workflow Rules still carry business logic, that is a finding: Salesforce has ended support for both and points customers to Flow, and moving off them is a redesign rather than a conversion.
The bigger question is coherence. Several Flows firing on the same object trigger, written by different people with no documented order, will produce results that depend on which runs last. Check for recursive triggers without a termination condition, database updates inside loops, and Flows that duplicate logic already handled in Apex, a typical result of team turnover: someone builds a Flow because nobody told them the Apex class existed.
3. Integrations
Map every external system that touches the org, including the undocumented ones: Connected Apps, Named Credentials and External Services, compared with actual API usage. For each connection, record the owner, the authentication method, the data volume and the error handling.
Two findings deserve attention. Integrations nobody can explain but that still run and consume API calls are both a security surface and a limit drain. Integrations running on a named person’s credentials depend on that person’s account, and nobody decides what happens when they leave. Whether a middleware layer is warranted depends on the number of systems and the transformation logic; the review should record that decision and its owner rather than assume an answer.
4. Security and access
Access models accumulate debt nobody sees: a few broad profiles plus a growing list of permission sets that nobody has reviewed. Count the users on the System Administrator profile and ask why each one is there. Compare org-wide defaults and sharing rules with actual business need; tightening an open model later is painful, while opening a restrictive one is easy. If permission set assignments grow faster than the user count, the access model is drifting.
If agents are planned, the same question extends to every action an agent can call: whose permissions it runs with, and who approved that scope.
5. Deployment discipline
How changes reach production says as much as what the org contains. Check that version control holds the reference state, that a sandbox mirrors production for final validation, that changes are reviewed before release, and that each release has a rollback plan. Drift between sandboxes and production, where nobody knows which one is authoritative, is what turns a routine release into a long rollback. Ask the team to name the reference environment. Hesitation is a finding.
Rank findings by blast radius and effort
A list of findings is not a plan. Rank each one on two axes. Blast radius is how many users, records or downstream systems are hit when it fails, and how often the conditions occur: a logic error on every Account update outranks a misconfiguration on an object used twice a year. Effort is how hard the fix is.
| Low effort | High effort | |
|---|---|---|
| High blast radius | Fix now: security misconfigurations, retired automation that focused work can migrate | Programme-level work with its own budget and phases: data model restructuring, integration redesign |
| Low blast radius | Technical debt backlog, worked through steadily: field cleanup, inactive automation, orphan permission sets | Park until a trigger raises the risk, such as a new integration or a second cloud |
Which quadrant gets funded decides whether the next major programme starts on a clean base or carries old decisions nobody wants to reopen. The note on technical debt covers how to run the backlog. If the org is already in distress, start with project rescue instead.
What to check
- The review covers all five areas, deployment discipline included.
- It includes interviews with the people who changed the org, not only tool output.
- Automation on core objects comes with a dependency map.
- Every finding carries a blast radius, an effort level and a named owner.
- The top findings fit on one page, and you can decide from it what to fund.