A thorough Salesforce org health check does one thing a deployment checklist cannot: it surfaces the compounding failures — the permissions quietly granting too much access, the automation conflicts buried three flows deep, the sandbox nobody has refreshed in six months — before they reach production users. Most go-live incidents are not caused by the feature that was just built; they are caused by the environment it was dropped into. These ten audit areas will tell you whether your org is genuinely ready or simply waiting to fail.
1 & 2 — Security, Permissions, and Sharing Rules
Permission bloat is the silent killer of Salesforce security posture. Start with a full export of your profiles and permission sets and cross-reference them against your actual user base. In most mature orgs you will find at least three things: system administrator profiles assigned to users who have no business having them, permission sets that were cloned for a single project and never cleaned up, and field-level security exceptions that were toggled on "just for testing" and never toggled back. None of these will throw an error. They will simply expose data they should not.
Organisation-Wide Defaults (OWD) are the second place most audits go wrong. If your OWD on a sensitive object is set to Public Read/Write because someone found it easier during a build phase, that is now your production setting. Before go-live, every object should have its OWD explicitly justified. Document the rationale in your org configuration notes — "Public Read/Write on Opportunity because sales reps need cross-territory visibility" is defensible. "Public Read/Write because it was easier" is not.
| What to Check | Red Flag | Remediation |
|---|---|---|
| System Admin profile assignments | More than 5% of active users | Reassign to least-privilege profiles or permission sets |
| OWD on sensitive objects | Public Read/Write on Case, Opportunity, or custom financial objects | Lock to Private and implement sharing rules explicitly |
| Permission set clones | Three or more sets with near-identical names and overlapping permissions | Consolidate and delete orphaned sets |
| Field-level security exceptions | Sensitive fields visible to all profiles | Audit via Setup > Security > Field Accessibility |
3 & 4 — Data Integrity and Duplicate Records
Duplicate data does not just produce bad reports — it drives bad automation. When a flow triggers on Account update and there are four duplicate accounts for the same customer, expect four sets of tasks, four emails, and four notifications to land in your service team's inbox within seconds of go-live. Run a deduplication analysis before launch, not after. The Salesforce Duplicate Management tool covers basic matching, but for anything with complex matching logic or high record volumes, a dedicated data quality pass is worth the time investment.
Required field gaps are the subtler data integrity risk. Check every custom object and critical standard object for fields that should be required but are not — particularly those that feed downstream reports, integrations, or SLAs. A Case without a priority value is not just messy; if your escalation automation keys off priority, that Case will never escalate. Map every automation dependency back to the field it reads from and verify that field has a required validation rule or default value preventing nulls.
Also audit data type mismatches that were introduced during migrations. Text fields storing dates, picklist values that no longer match the current picklist definition, lookup fields pointing at inactive records — these accumulate silently and produce the kind of runtime errors that only appear under specific conditions, which is to say, conditions that only occur in production.
5 & 6 — Automation Conflicts and Validation Rule Coverage
Automation is where the most time-consuming go-live issues originate. The Salesforce platform now runs flows, Process Builder processes (yes, some orgs still have them), before-save flows, Apex triggers, and workflow rules, all potentially on the same record at the same time. The order of execution is defined, but the interactions between automations are not validated by the platform — that is your job. Before go-live, produce a full automation inventory per object: list every trigger, flow, and process, annotate what each does, and identify any that write to the same field or send the same type of notification. Conflicts that are invisible in a developer sandbox will blow up in full sandbox under realistic data conditions.
Legacy Process Builder processes deserve special attention. Salesforce has been deprecating Process Builder since 2023, and any process still running in your org is technical debt with a timer on it. Use this audit as the forcing function to migrate remaining processes to flows. The migration effort is almost always smaller than it looks, and completing it before go-live means you are not inheriting a deprecated dependency on day one.
Validation rules need coverage auditing in both directions. First, are the rules that should exist actually in place — particularly on objects that receive data from integrations or API calls, where UI-enforced required fields are bypassed entirely? Second, do any validation rules conflict with each other or with automation logic? A validation rule that fires on an automated field update and blocks a legitimate process will surface as a confusing error in your users' activity logs rather than a clean exception.
Stop discovering sandbox problems in production
SproutEzee handles sandbox creation, seeding, and refresh at scale — so your environments actually reflect production before you need them to.
See SproutEzee →7 & 8 — Sandbox Environment Parity and Refresh Cadence
Here is a scenario that plays out in real go-lives with uncomfortable regularity: the team has been building and testing in a developer sandbox, the full sandbox refresh that was requested three weeks ago still has not completed, and the partial sandbox from last quarter has a metadata gap of four major feature releases. The go-live proceeds. Two automations that worked perfectly in the developer sandbox fail in production because the full sandbox would have revealed an interaction with a third-party managed package that was updated in production but never synced down. Sandbox parity is not a nice-to-have — it is the control environment for your entire QA process.
Auditing sandbox health means checking three things: when each sandbox was last refreshed, what its current metadata version is relative to production, and whether it has been seeded with representative data. A sandbox refreshed six months ago is not a test environment — it is a historical artefact. For teams running regular release cycles, partial sandbox refreshes every four to six weeks and full sandbox refreshes aligned to major releases is the minimum bar. The difficulty is that Salesforce's native sandbox refresh tooling does not give you granular scheduling, automated seeding, or masking of production data before it lands in a lower environment. That gap is exactly where tools like SproutEzee close the loop — managing refresh schedules, seeding environments with the right data shape, and doing it at a scale that manual refresh workflows simply cannot sustain.
Data masking in sandboxes is non-negotiable for any org holding personal data under GDPR. If your partial or developer sandbox contains real customer names, email addresses, or phone numbers, you are in breach of your data processing obligations — regardless of whether that data has ever left the sandbox. Audit which sandboxes exist, what data they contain, and whether masking was applied at the point of refresh.
9 — Integration and API Health
Every connected app and named credential in your org is a potential failure vector at go-live. Run a full inventory of your integrations: the middleware platforms (MuleSoft, Boomi, Jitterbit), the direct API connections, the Salesforce Connect external objects, and any third-party managed packages that make outbound callouts. For each one, verify that the authentication credentials are current, that the connected app's OAuth scopes are minimal and correct, and that the API user running the integration has exactly the permissions it needs — no more.
Governor limits deserve a dedicated check when integrations are in scope. An integration that makes 50 API calls per hour in UAT will make 5,000 per hour in production under real load. Check your current daily API limit consumption in production, model the expected increase from new features, and verify there is headroom. The same applies to bulk API limits, SOQL query limits in Apex, and callout limits. Teams that migrate from Change Sets to proper deployment pipelines — Gearset, Copado, or similar — often discover limit issues in this audit that were invisible in manual deployment workflows.
10 — Apex Test Coverage and Technical Debt
Seventy-five percent Apex test coverage is the Salesforce deployment minimum, not the quality standard. An audit that simply confirms you meet the threshold is not actually auditing code quality — it is confirming you will not be blocked at deployment. For a genuine go-live readiness assessment, look at coverage distribution: are your most complex classes the ones with the lowest coverage? Is coverage coming from tests that actually assert expected outcomes, or from tests that exist purely to inflate the line count? A class with 80% coverage and zero assertions is worse than useless — it will pass deployment and tell you nothing when behaviour changes.
Identify and document your technical debt before go-live, not as a reason to delay, but as a risk register for the first 90 days post-launch. Hard-coded record type IDs, SOQL queries inside loops, synchronous callouts that will time out under load — catalogue them, assign owners, and set remediation timelines. Going live with known technical debt is acceptable; going live without knowing it is on the list is how you end up in an incident review explaining why a known risk was never mitigated.
Frequently Asked Questions
How long does a Salesforce org health check typically take?
For a mid-sized org with 50–200 active users and a moderate customisation footprint, a structured health check covering these ten areas typically takes two to four days of focused effort. Larger orgs with complex automation stacks, multiple integrations, and years of accumulated technical debt can take one to two weeks. The output should be a prioritised remediation list, not just a status report — categorise findings by severity and whether they are blockers for go-live or post-launch improvements.
Should a health check be done in production or a sandbox?
The analysis is done against production metadata and configuration — that is where the real state of your org lives. Running the audit against a stale sandbox would give you an inaccurate picture. However, any remediation work identified during the audit should be built and tested in a sandbox before being deployed back to production. This is precisely why sandbox parity (item 7 above) matters so much: if your sandbox does not reflect production, your remediation testing is unreliable.
What tools can assist with a Salesforce org health check?
Salesforce's own Security Health Check (Setup > Security > Health Check) covers a subset of security settings and is a useful starting point. For deeper analysis, Salesforce Optimizer generates a report across automations, custom code, and storage. For sandbox environment management, refresh scheduling, and data masking, SproutEzee fills the gap that native tooling leaves. For deployment pipeline health and metadata comparison, Gearset and Copado both offer org comparison tooling that surfaces configuration drift between environments.
How often should a Salesforce org health check be performed?
A full health check should be a pre-requisite before any major go-live — new implementations, significant feature releases, or post-acquisition org merges. Outside of those events, a lighter-touch review of security settings and automation health every six months is a reasonable cadence for organisations with active development teams. Orgs that have been in a maintenance-only state for a year or more often benefit from a full audit before resuming active development, because entropy accumulates even when nobody is deliberately making changes.
What is the single most common finding in a Salesforce health check?
Permission bloat — consistently. Profiles and permission sets that were expanded during development and never tightened before go-live, or that accumulated exceptions over multiple release cycles without review, account for the majority of security findings across most org audits. The second most common finding is automation conflicts: two or more automations on the same object that interact in ways the authors did not anticipate, producing behaviour that only manifests under specific data conditions. Both are entirely preventable with a structured audit process before launch.
A Salesforce org health check is not a one-time gate — it is evidence that your team treats production as a controlled environment rather than a place where surprises happen. The ten areas covered here represent the categories that generate the most post-go-live incidents: security and permissions, data integrity, automation conflicts, validation coverage, sandbox parity, integration health, and code quality. Address them before launch and you are not just reducing risk; you are building the operational discipline that makes every subsequent release faster and less stressful. The orgs that skip this audit are the ones whose go-live stories start with "it was fine in the sandbox."