Org Health Assessment: How to Diagnose a Struggling Salesforce Org

What a Health Assessment Is — and Isn't

An org health assessment is a systematic review of a Salesforce org across four dimensions: technical, adoption, governance, and data quality. Its purpose is to provide an evidence-based picture of the org's current state — what is working, what is degrading, and what is at risk of failure.

It is not a licence to rebuild from scratch. "The org is a mess, we should start over" is almost never the right conclusion. Rebuilding from scratch discards the institutional knowledge embedded in existing configuration, disrupts users who have adapted their workflows to the current system, and typically replicates the same governance failures that created the original problems. The output of a health assessment should be a prioritised remediation plan — specific interventions for specific problems — not a recommendation for wholesale replacement.

It is also not an audit. An audit is backwards-looking and compliance-focused. A health assessment is forward-looking and capability-focused. The question is not "did we follow our own policies?" but "is the org in a condition to support the next phase of platform investment?"

Dimension 1: Technical Health

Technical health covers the state of the org's code, configuration, and infrastructure. The signals of poor technical health are usually visible before you run any tools — users report errors, deployments take a long time, releases break unexpected things.

Governor Limit proximity. Check SOQL queries, DML operations, and heap size usage in critical transactions. Apex code running close to governor limits is fragile — future changes may tip it into failures. Use Salesforce's Event Monitoring or Debug Logs to identify high-risk transactions.

Automation layering. Count the total number of active automations (Flows, Workflow Rules, Process Builders, Apex Triggers) on your most-used objects (Lead, Opportunity, Contact, Case). More than 10-15 automations on a single object is a warning signal. Overlapping automations create unpredictable order-of-execution issues and make debugging nearly impossible. Check for deprecated automation types: all Workflow Rules and Process Builders should have been migrated to Flow by now; if they haven't, that is technical debt.

Apex code quality. Review code coverage across all Apex classes. Classes below 75% coverage indicate undertested code. Look for hardcoded IDs, SOQL inside loops, and methods exceeding 200 lines — these are the most common code quality problems. Static analysis tools (PMD, Clayton) can automate this review.

AppExchange package inventory. List all installed packages, their last upgrade date, and their active usage (does anyone use this?). Packages not upgraded in 12+ months are a compatibility risk. Packages with zero active usage should be evaluated for removal.

Metadata volume. Are you approaching limits on custom objects (2,000), custom fields per object (500), or Flows? Approaching these limits constrains future development options. High metadata volume also correlates with complexity debt — the presence of many custom objects suggests previous decisions to build rather than configure.

Dimension 2: Adoption Health

Adoption health assesses whether users are engaging with Salesforce in ways that generate business value. The signals of poor adoption health are operational: pipeline reports that don't match what sales managers believe, service metrics that don't reconcile with ticket volumes, and managers who compile performance data from spreadsheets rather than Salesforce reports.

Review the three-tier adoption framework from ENT-017: access adoption (are users logging in), process adoption (are they completing critical tasks), and insight adoption (are managers using Salesforce data for decisions). For each tier, establish the current baseline against expected targets for the org's maturity level.

Interview 8-10 users across different roles and business units. Ask: what do you use Salesforce for on a typical day, what do you find frustrating, what do you do outside Salesforce that you think should be in it? These interviews surface shadow processes — parallel tracking systems in spreadsheets or email that indicate where Salesforce is failing to support the user's actual workflow.

Interview 3-5 managers. Ask: when you review your team's performance, what data source do you use? Do you trust the Salesforce data? What would make you rely on it more? Manager trust in Salesforce data is the single most reliable indicator of overall adoption health.

Dimension 3: Governance Health

Governance health assesses whether the processes, roles, and decision-making structures that should govern the platform are in place and functioning. Poor governance health is the root cause of most technical and adoption problems — it is what allows technical debt to accumulate and adoption problems to persist.

Check for the following governance signals:

Change management process. Is there a documented change control process? Are all production changes deployed through a tested release pipeline, or are some changes made directly in production? Direct production changes are a strong signal of governance failure — they produce undocumented configuration, deployment conflicts, and data loss risk.

Environment strategy. Does the org have a sandbox hierarchy (Developer/Developer Pro, Partial/Full sandbox) that reflects its complexity? Orgs without a Full sandbox cannot test realistic data volumes before deploying changes — this is a risk for any org with more than 100,000 records.

Profile and permission set design. Are permissions managed through a well-designed permission set architecture, or through over-privileged profiles and ad hoc sharing rules? Too many profiles (more than 20 for most orgs) and too many sharing rules indicate governance erosion.

Documentation. Is there current documentation for the data model, integration architecture, and key automations? Orgs where knowledge exists only in the heads of specific individuals are fragile — staff changes create knowledge loss that takes months to recover.

Scoring, Prioritisation, and the Remediation Plan

Assessment findings need to be scored by severity (critical/major/minor) and by impact (business impact of addressing vs not addressing). The combination of severity and impact determines prioritisation.

Critical findings — those that represent active risk of system failure, data loss, or compliance breach — should be addressed immediately, outside of normal release cycles if necessary. Examples: Apex code at governor limit proximity, production changes being made without testing, security vulnerabilities in permission design.

Major findings — those that are impairing adoption, slowing delivery, or creating significant technical debt — should be addressed in a structured remediation sprint within the next quarter. Examples: automation layering on critical objects, low adoption in key teams, undocumented integrations.

Minor findings — those that represent debt but not active impairment — should be addressed through ongoing housekeeping over the next 6-12 months. Examples: unused custom fields, outdated AppExchange packages, documentation gaps.

Present the remediation plan with business impact framing: not "we need to fix 47 technical issues" but "our current technical debt is adding X weeks to each release cycle, costing approximately £Y per month in delayed delivery. The following remediation will recover this within 6 months." This framing makes the remediation fundable as a business investment rather than a technical maintenance activity.