The State of Salesforce Org Health 2026 — A Cross-Org Telemetry Report

Executive summary

Every quarter, BuildForce runs more than two hundred automated system checks across each connected Salesforce production org — measuring security posture, code quality, automation hygiene, permission sprawl, data quality, Connected App configuration, release readiness, and Agentforce / Einstein integration health. For this report we aggregated 12 months of those runs across 245 distinct production orgs and removed every customer-identifying field before computing the cross-org statistics below.

The picture that emerges is not the polished benchmark Salesforce customers often see in vendor case studies. It is the operational reality of how production orgs actually look at scale — including the orgs you can usually only get access to via expensive consulting engagements. The headline numbers are uncomfortable: the typical org passes only 68% of the system checks BuildForce runs against it, a number that has crept up over the year but still leaves roughly one in three checks in a failing state at any given moment.

More importantly, four very specific platform shifts are now converging on every org simultaneously: (1) deprecated API version retirement, (2) the Connected App → External Client App (ECA) migration, (3) Workflow Rule and Process Builder end-of-life, and (4) the Agentforce / Einstein integration tier shift. Each one alone is manageable. Stacked, they form the single largest forced migration in the platform's recent history. This report quantifies how prepared the average org is — and how prepared the average org is not.

Three observations matter most for executives reading this. First, the gap between best-in-class orgs and the median is much wider than the published industry benchmarks suggest. Top-quartile orgs sit above 85% pass rate on the same check set where the median sits in the high-60s. The difference is not the org's size or vertical — it's whether the org has continuous automated remediation or relies on engagement-based consulting. Second, the convergence risk is concentrated in a small minority of orgs. Roughly 19% of orgs sit in the critical tier (sub-60% pass rate). These orgs carry multiple severity-critical findings across two or more categories simultaneously, and they are statistically the ones most likely to be blindsided by Spring '26. Third, the findings that drive the most remediation time are not the findings most leadership teams worry about. Custom-field cleanup and Apex test coverage win on hours-of-work, but deprecated APIs and ECA migration win on platform-risk impact — and the two sets barely overlap.

For anyone leading a Salesforce, RevOps, or platform-engineering org, the implication is straightforward. The next four quarters are the most important platform-debt window in the last decade. The orgs that come out of Spring '27 with a clean health-check posture will be the ones that started moving in Q2 of 2026. The orgs that wait will be the ones writing consulting checks for the same work two years from now.

Finding 1 — Deprecated API versions are still running in production at most orgs

Salesforce has formally deprecated API versions 21.0 through 30.0 and announced that retirement will begin in Summer '26. Despite ample lead time and multiple Salesforce release notes calling out the deprecation, the BuildForce telemetry shows that the vast majority of analyzed orgs still have at least one production code path — Apex classes, Apex triggers, named-credential integrations, or Connected App configurations — calling a deprecated version.

The exposure surface is broader than most teams expect. BuildForce's detection covers (a) ApiVersion fields on ApexClass, ApexTrigger, ApexPage, and Lightning components; (b) versioned REST and SOAP endpoint calls in integration payloads; (c) named credential and external service definitions; and (d) Connected App API version overrides. In practice, the most common offender is a legacy integration written years ago against a then-current version (often v28.0 or v29.0) that never got upgraded because “nothing was broken.”

That last sentence is the trap. Salesforce's API version policy is forward-compatible until it isn't. The retirement window is when previously-working integrations start failing quietly — or, worse, when they start returning slightly different payloads because behavior of a long-fixed bug was inverted in the current API. Diagnosing those failures after the fact is much harder than upgrading the version proactively.

For a deep dive into the API version upgrade path — including how to audit which classes call which version — see our Apex governor-limits diagnostic guide and the broader BuildForce Health Check feature page for the full check-list.

Why the upgrade is harder than it looks

The mechanical upgrade — changing the ApiVersion field on a metadata file — is trivial. The hard part is what the upgrade exposes. Each Salesforce API version ships a handful of silent behavior changes that affect deserialization edge cases, null-vs-empty-string distinctions, and the way related-list queries hydrate child records. Most of those changes are documented in the release notes, but they're scattered across multi-hundred-page documents that nobody reads cover-to-cover.

The pattern BuildForce sees most often is that a team upgrades an Apex class's API version, ships it, and then sees a subtle defect surface a week later in the test environment that ends up tracing to a change in how a particular SObject relation serializes. The fix is small once you find it, but the triage is expensive. Teams that batch their API upgrades and allocate test-engineer time to walking the diff between two versions consistently produce cleaner outcomes than teams that upgrade one class at a time as they touch it.

Where the deprecated calls actually live

Across the dataset, the most common sources of deprecated API calls (in rank order) are: (1) named credentials and external services pointed at /services/data/v28.0 or earlier endpoints, (2) Apex classes written between 2017 and 2019 that were never refactored, (3) Connected Apps with an explicit apiVersion override in the package manifest, and (4) Lightning components built on the Aura framework before the LWC migration. The Connected App path is the most dangerous because it's the one most likely to be invisible — a Connected App created years ago can be calling a deprecated API from a vendor's server with no Apex log trail in your own org.

What to do this quarter: Run an org-wide inventory of ApiVersion values across all Apex, Lightning, and named-credential metadata. Anything ≤ v30.0 needs an upgrade ticket created and routed before the Summer '26 release. BuildForce surfaces this as check API_001 in every health-check run.

Finding 2 — The Spring '26 External Client App migration is barely underway

External Client Apps are Salesforce's next-generation replacement for Connected Apps and the platform's recommended OAuth surface beginning with Spring '26. Connected App creation will be disabled in new orgs by Spring '26 GA, and existing Connected Apps will continue to function but will not be a permitted surface for new integration development.

ECAs differ from Connected Apps in three ways that materially change the security posture: (1) ECAs use a closed-posture security model that requires the consumer to install a 2GP managed package before authentication is possible, eliminating the global-exposure attack surface that Connected Apps had; (2) the OAuth client credentials live inside the package, not the installing org; and (3) the auth flow supports cleaner cross-tenant attribution for ISVs and partners.

The BuildForce numbers show how early the ECA migration still is. More than four of every five analyzed orgs have not yet installed any ECA package. Of the orgs that have an ECA-enabled connection, the majority are running it alongside a legacy Connected App — i.e. they have not fully cut over.

The longer the migration gets delayed, the worse it goes. Once Spring '26 ships, every new integration project will need to choose between (a) writing against the Connected App surface knowing it's deprecated, or (b) building the package-installation workflow into the integration's onboarding. Most teams will choose (a) under pressure and create additional debt that has to be unwound later.

For more on the ECA architecture, BuildForce's implementation walkthrough lives in the BuildForce docs. Customers using BuildForce's built-in OAuth broker can flip between Connected App and ECA without rewriting their integration code, as documented in the Salesforce Optimizer alternative comparison.

The cross-vertical breakdown

ECA migration progress varies significantly by vertical. Public Sector and Healthcare / Life Sciences orgs sit furthest behind — fewer than 8% have an ECA-enabled connection in production — because the security-review cycles in those verticals are long and the cross-team coordination required to install a 2GP managed package in a production tenant is non-trivial. Technology / SaaS orgs lead the migration with roughly 22% ECA-enabled, mostly driven by ISVs that have to ship ECAs to their customers regardless. Financial Services and Manufacturing sit in the middle (12–15%).

The pattern here matters because it predicts which verticals are going to hit the Spring '26 GA wall hardest. Verticals already behind on ECA also tend to be the same verticals that run more Connected Apps overall — the bloat compounds.

What “fully migrated” actually means

Salesforce's ECA migration is more than swapping the OAuth surface. A fully-migrated org has: (a) a 2GP managed package created in a DevHub-enabled production org, (b) the package installed in every consuming org, (c) consumer's OAuth flows updated to reference the ECA client ID rather than the Connected App client ID, (d) refresh-token policies updated to the ECA equivalents, and (e) the legacy Connected App revoked or deleted. Across the dataset, fewer than 4% of orgs that have “started ECA” have completed all five steps. The modal “ECA org” has done step (a) and (b) but not yet (c), which means the legacy Connected App is still doing the work.

What to do this quarter: Create your DevHub-based 2GP managed package now, even if you don't flip the production switch until Spring '26. The package-creation and security-review timeline is typically 4–8 weeks; teams that start in late Q2 have margin, teams that start in Q4 will not.

Finding 3 — Two-thirds of orgs still run Workflow Rules or Process Builder

Salesforce announced the Workflow Rule and Process Builder end-of-life multi-year plan back in 2022, and the official retirement target remains 2027. Despite four years of advance notice, BuildForce's cross-org telemetry shows that more than three out of five analyzed orgs still have at least one active Workflow Rule or Process Builder. About a third have more than ten of them.

The challenge here is not that teams don't know about the EOL — every Salesforce admin we've talked to is aware. The challenge is sequencing. Most Workflow-to-Flow migrations end up on the backlog behind release work, then get pushed when a critical-priority field deletion hits, then get pushed again when an integration breaks. By the time the migration actually starts, the org has accumulated additional automations on top of the legacy ones, making the migration scope larger than it would have been if started two years earlier.

BuildForce check AUTO_001 surfaces every active Workflow Rule with the recommended Flow equivalent and a BuildForce-generated migration plan that includes test coverage steps. AUTO_006 performs the same analysis for Process Builder. Customers using the BuildForce remediation workflow typically migrate 8–15 automations per sprint once the workflow is wired in.

See our companion Workflow Rule deprecation diagnostic guide for the per-automation migration recipe. For a perspective on why Flow consolidation is the right architectural choice (and not just the only option Salesforce gives you), see our $47,000 disaster post-mortem which traces a real-world per-record-save Process Builder failure.

Why the migration stalls

From the BuildForce telemetry it's clear that the most common stall pattern is: (1) team starts the migration with the highest-volume Workflow Rule, (2) discovers that the Flow equivalent has subtle semantic differences (e.g. how DML cascade behavior interacts with cross-object updates), (3) spends two sprints stabilizing the first migration, (4) loses stakeholder confidence in the timeline, (5) the migration de-prioritizes behind a release deadline, and (6) doesn't resume for another quarter. The pattern shows up in roughly 40% of the orgs that have started but not completed a Workflow-to-Flow migration.

The remediation is structural: don't pick the largest Workflow Rule first. Pick the smallest, lowest-risk one, build a test harness around it, ship it, and only then move to the next one in priority order. Teams that follow that sequence consistently complete the migration within 2-3 quarters; teams that try to “knock out the big one first” routinely overrun by a year or more.

The Flow-debt trap

One pattern worth calling out: among the orgs that have “completed” the Workflow-to-Flow migration, roughly a third have simply moved the same logic into Flow without consolidating it. The result is a per-object Flow proliferation that mirrors the legacy Workflow Rule proliferation — just in a different framework. BuildForce check PROC_001flags per-object automation collisions (more than three frameworks firing on the same object). It appears in the top 10 failures of this report precisely because the Flow migration keeps generating new instances of the collision.

The architectural answer is the Single-Flow-Per-Object pattern, in which a single record-triggered Flow on each major object orchestrates all downstream subflows via decision branches. Salesforce has been publishing this pattern in their Architects Library for a couple of years; the orgs that adopt it score noticeably higher on the BuildForce process-intelligence checks than the orgs that don't.

Finding 4 — Automated remediation is roughly 50× faster than the consulting baseline

For severity=critical findings, the median time from created_at (the moment BuildForce's scanner flags the issue) to fixed_at (the moment the remediation completes and the next run confirms the finding has cleared) is 4.2 hours across BuildForce-monitored orgs. For the same finding class, traditional consulting engagement timelines published by major Salesforce partner firms range from 10 to 14 days — roughly 50–80× longer.

The gap reflects three structural differences:

1. Continuous vs engagement-based. Consultants are dispatched per ticket. BuildForce runs continuously, so there is no ticket-creation overhead, no triage queue, and no cold-start onboarding.
2. Pre-computed remediation plans. Most of BuildForce's system checks ship with a parameterized remediation function. When the check fires, the fix is one click away — including dry-run preview, rollback snapshot, and audit log.
3. Cross-platform context. BuildForce knows about the rest of the customer's SaaS stack (HubSpot, ServiceNow, Marketo, etc.) and can flag downstream impacts before the fix runs — something consultants typically don't have visibility into.

None of that is to say BuildForce replaces consultancy work entirely. Strategic engagements — process redesign, executive advisory, M&A migrations — still require humans. But the tactical remediation work that fills most consulting engagements today is exactly the work most easily automated.

For a side-by-side comparison of BuildForce vs traditional managed-services engagements, see our managed services comparison and the broader replace your Salesforce consultant case study.

The remediation-time distribution

The median is the headline, but the distribution matters more. The 90th-percentile remediation time on BuildForce-monitored orgs sits around 28 hours — still well inside the consulting baseline. Where the long tail comes from is interesting: roughly 60% of the orgs in the p90+ bucket have at least one finding that requires a customer-side approval workflow before BuildForce can auto-apply the fix (for example, a security-policy change that needs CISO sign-off). The remaining 40% are findings in categories where the auto-resolution flow doesn't exist yet — typically deep platform integration work that BuildForce generates a remediation plan for but doesn't execute autonomously.

What it means for staffing

The implication for platform-engineering and admin teams is structural. If continuous remediation takes 4-5 hours for the average critical finding, then the work historically done by a single Salesforce admin can be done by a much smaller team — or redirected to higher-value work like enabling new business capabilities. Across the BuildForce customer base, we see two distinct patterns: (a) admin teams stay roughly the same size and pull in significantly more strategic work, or (b) teams keep the strategic load constant and reduce headcount. Both outcomes show up in the data; the choice depends on the org's growth ambitions, not on the platform.

Finding 5 — OAuth bloat is real and getting worse

BuildForce detects the count of active Connected Apps per org via two paths: (1) InstalledSubscriberPackage + ConnectedApplication SOQL queries, and (2) the cached metadata snapshot on the platform_connections row. We band the result into four ranges: 0–5, 6–15, 16–40, and 41+.

The 41+ band is the OAuth-bloat zone. Orgs in this band carry elevated risk for three reasons: (a) every additional Connected App is an additional credential that can be compromised; (b) security reviews require touching each app to certify scope and IP-restriction policy, so the review cost scales linearly with the count; and (c) the cross-app permission lattice gets large enough that no human can reason about the full attack surface from memory.

Two specific Connected App configurations are over-represented in the failures. First, Connected Apps with the full OAuth scope and no IP restriction (check CA_001) appear in nearly half of the highest-bloat orgs. Second, Connected Apps without a refresh-token-revocation policy (check CA_002) appear in roughly the same band. Together they form the most common OAuth misconfiguration pattern BuildForce sees.

The Spring '26 ECA migration is, in part, Salesforce's answer to this. ECAs do not eliminate the bloat problem mechanically, but they do give security teams a cleaner audit surface and a faster path to revoke individual apps at scale.

Bloat sources, ranked

Where do the extra apps come from? Across the 41+ band, the sources rank: (1) ISV-installed packages that ship Connected Apps as part of their installation (LinkedIn Sales Navigator, Outreach, Gong, etc.) — these account for roughly 35% of the total in a typical bloated org; (2) one-off integrations authored by internal teams over multiple years where the original author has left the company — about 25%; (3) demo or sandbox-leftover Connected Apps that were promoted to production and never cleaned up — about 15%; (4) inactive but not deleted Connected Apps from sunsetted business systems — about 15%; (5) duplicate Connected Apps created during ISV re-installations — about 10%.

The most efficient cleanup wins target categories (3), (4), and (5) first. Category (2) is the hardest because no one knows what it does. Category (1) is non-discretionary — you can't remove a vendor's Connected App without uninstalling the vendor's package, which usually requires renegotiating the contract.

The blast-radius math

Each Connected App with the full scope and no IP restriction represents an OAuth credential that, if compromised, can read and write every record the credential's user can access. In an org with 40 such apps and 4 of them holding admin-equivalent permissions, a single compromise of one of those four would give an attacker effectively unbounded access. BuildForce's security team has reviewed dozens of orgs where the credential-compromise blast radius traces back to a Connected App that hadn't been touched in 3+ years.

Finding 6 — A quarter of orgs are in the highest technical-debt band

BuildForce computes a per-connection technical_debt_score (and a fallback customization_score when the debt-score signal is unavailable) from a weighted sum of: (a) custom-object volume vs standard-object usage; (b) per-object automation collisions (multiple frameworks firing on the same object); (c) unused custom-field ratio; (d) Apex test coverage below 75%; (e) deprecated metadata still active; (f) Process Builder / Workflow Rule prevalence; and (g) deferred-but-deprecated API version usage.

Roughly a quarter of analyzed orgs sit in the highest band (76–100). These orgs typically share three properties: large tenure (3+ years on the platform), high org-merge history (acquisitions are a major debt-generator), and at least one “let's rebuild this on Flow” project that stalled mid-flight. The data is also clear that orgs in the highest-debt band see roughly 3–4× more deployment failures than orgs in the lowest band, even normalizing for deploy frequency.

The good news is that debt is reducible. Customers who run the BuildForce auto-resolution workflow on the highest-impact findings typically shed 10–20 score points per quarter for the first two quarters before the curve flattens. For a deeper look at how BuildForce's scoring works against the alternative Hubbl benchmarking approach, see the SaaS management platforms comparison.

The correlations worth flagging

Three correlations show up consistently in the dataset: (a) orgs that have completed an M&A integration in the last two years sit, on average, 18 points higher in technical-debt score than their non-M&A peers — acquisitions are the most reliable single source of net-new platform debt; (b) orgs with three or more concurrent Salesforce clouds (Sales + Service + Marketing + Data Cloud, etc.) score roughly 12 points higher than single-cloud orgs, almost entirely because of the cross-cloud automation surface; and (c) orgs that have rotated their Salesforce admin lead in the last 12 months sit 8-10 points higher than orgs with continuous admin tenure.

None of those correlations are causal in the strict sense — an M&A doesn't add debt by itself; the debt accumulates because the post-merger integration runs faster than the architectural-debt repayment work. But the correlations are stable across the dataset and predictive enough that BuildForce uses them to set per-org baselines.

What “good” looks like

The orgs in the 0-25 band share a small set of characteristics. They have a single dedicated platform-owner role with veto rights on metadata changes. They run the BuildForce auto-resolution workflow on all severity-medium-and-above findings without manual triage. They keep their Apex test coverage above 80% (not the 75% Salesforce floor). And they ship Salesforce changes via a CI/CD pipeline with automatic backward-compatibility validation. The pattern is consistent enough across the band that BuildForce considers it the recommended target operating model for any org that wants to move out of the higher debt bands.

Finding 7 — The top 10 health-check failures by frequency

Aggregating across all 200+ system checks BuildForce runs, the failures below appear in the highest percentage of analyzed orgs. The ranking is stable quarter-over-quarter — the same checks have led the list for the entire 12-month window, with ordering shifts only inside the top 5.

Two patterns are worth flagging. First, four of the top ten failures are in the “platform shift” category — they exist because Salesforce changed something (API versions, automation framework, OAuth surface) and the org hasn't kept up. The other six are accumulated debt from changes the org itself made and never cleaned up after.

Second, the severity distribution skews high. Six of the ten are tagged severity ≥ high. There is no top-ten finding tagged severity ≤ low — meaning the most common failures across the dataset are also the ones most likely to cause production incidents.

For an interactive view of the same data scoped to your own org, every BuildForce trial includes the full failure-frequency report in the first health-check run. See the Salesforce health check trial or jump straight to Fix My Health Check to run one against your own production org.

What surprised us in the top-10

Two findings in the top 10 surprised the BuildForce team. First, the API-version finding (rank 1) appears across roughly the same percentage of orgs in every vertical — we expected to see a heavy concentration in Manufacturing and Public Sector, but the prevalence is broadly even. Second, the duplicate-record finding (rank 9) is lower than we expected. Most published data-quality benchmarks suggest duplicates above 10% in B2B CRMs; the BuildForce dataset shows orgs aggressively cleaning up duplicates over the window, with the median duplicate rate now sitting below 5% on core sObjects.

What's NOT in the top 10 (and why that matters)

A few categories are notable for their absence from the top list. Einstein and Agentforce-related findings appear in only 12-18% of orgs because Einstein/Agentforce adoption is itself still under 30% in the dataset. Once adoption widens through 2026, expect these checks to move up the failure-frequency ranking quickly. Similarly, Data Cloud (formerly CDP) integration findings appear in only 9% of orgs today, but Data Cloud's share of new Salesforce deployments is growing roughly 4x year-over-year. Both categories will likely be in the top 10 by the next quarterly report.

Finding 8 — Aggregate org health is trending up, slowly

The 12-month trend shows that the cross-org health score is inching upward — about 8 points of pass-rate improvement over the window — but the rate of change is modest and most months see only ±1-2 points of movement.

What's driving the slow upward drift? Three contributing forces, ranked by impact in the data: (1) more orgs adopting continuous automated remediation, which shows up as a per-org score increase in the months after onboarding; (2) Salesforce release notes prompting org owners to clean up specific debt categories ahead of Winter '25 and Spring '26 GA; and (3) the addition of BuildForce auto-resolution workflows that clear several common categories without explicit human intervention.

What's holding the curve back? Mostly the four platform shifts we've described above. Until they finish landing, individual orgs will accumulate new findings (deprecated APIs, unmigrated automations, ECA-conversion checks) at roughly the same pace as they remediate existing ones. We expect the curve to inflect more clearly once Spring '26 GA forces the ECA and API-version remediation to the front of the queue.

The dip in December

One data quirk worth explaining: the score dipped roughly 2 points in December 2025 before resuming the upward trend in January. That dip is consistent across the dataset and traces to two compounding factors. First, the Winter '26 release shipped in October introduced a batch of new system checks (security_baseline updates, the first wave of ECA-readiness checks) that fired against existing orgs and produced a step increase in the failure count. Second, December tends to be a slow remediation month — code freezes, holiday calendars, and release windows mean less work gets shipped. The combination produces the dip. It is not a real worsening of org health; it is the score catching up to the new check set.

Bonus finding — Agentforce and Einstein adoption is shallow, but accelerating

Across the 12-month window, the percentage of analyzed orgs with at least one provisioned Agentforce agent or Einstein Copilot configuration tripled. The starting baseline was low (under 10% in May 2025), but the growth rate is consistent with the rest of the AI-native platform tooling ecosystem. Adoption is now sitting just under 30%.

The catch is that adoption is shallow. Of the orgs that have provisioned an agent or Copilot configuration, only roughly one-third have moved it into production-grade usage with governance controls, audit logging, and a security review completed. The rest sit in an “evaluated but not deployed” state. The pattern is consistent with what one would expect of an early-tier AI feature; it is also consistent with the BuildForce-observed pattern that the security-review queue is the single largest blocker on production AI deployment in Salesforce orgs today.

What this means for the report: Einstein/Agentforce-related findings appear in only 12-18% of the failure-frequency distribution today, but the count is rising quickly. Expect Einstein governance checks (AI_001, AI_004, AI_007) to move up the ranking through 2026 as adoption widens. Orgs considering an Agentforce deployment should treat the security-review timeline as the long pole and stand it up ahead of the technical work, not after.

Industry comparison — how verticals differ

The dataset draws from six broad verticals, with Technology / SaaS over-represented relative to the broader Salesforce customer base. Healthcare / Life Sciences and Public Sector orgs are over-represented in the highest-severity findings because of the compliance overhead each carries; their average pass rate sits 4–6 points below the cross-vertical mean.

Verticals with heavier compliance requirements — Healthcare / Life Sciences, Financial Services, Public Sector — have measurably more findings in the security and permissions categories but fewer findings in the automation and code quality categories than Technology / SaaS orgs. The interpretation is straightforward: regulated verticals spend their automation budget on compliance controls and have less margin for unbounded customization. Technology / SaaS orgs do the inverse.

Manufacturing orgs are an interesting outlier. They have relatively low automation-finding counts and relatively low security-finding counts, but they have the highest concentration of deprecated-API findings in the dataset. The pattern is consistent with long-tenured orgs that built integrations once (typically against the v28-v30 era) and have been treating them as production-stable ever since.

The size-of-org effect

Org size — measured by either user count or annual contract value — predicts technical-debt score weakly but not health-check pass rate. Said differently: bigger orgs accumulate more raw findings (they have more surface area to scan), but their average findings-per-area-of-platform ratio is roughly the same as smaller orgs. The implication: the org-health problem is structural, not scale-driven. A 50-user org and a 5,000-user org show roughly the same pattern of weakness in the same categories. The differences emerge in how each org responds — larger orgs have more headcount available to triage, but also tend to have longer change-management cycles that slow remediation.

The single-Salesforce-cloud vs multi-cloud split

Multi-cloud Salesforce orgs (those running Sales Cloud + Service Cloud + Marketing Cloud or Data Cloud) carry an average 6-point penalty on the cross-org health score relative to single-cloud orgs. The penalty is heavily concentrated in two categories: automation collisions (where the same record triggers automations across multiple clouds) and integration drift (where the cross-cloud sync runs on an outdated API contract). It is not a verdict on the multi-cloud strategy itself — multi-cloud is the right architecture for many verticals — but it does mean that multi-cloud orgs need roughly 30% more platform-engineering investment to stay at the same health score as their single-cloud peers.

Recommendations — what to do this quarter

1. Audit your API version footprint. Inventory ApiVersion across all Apex, Lightning, and named-credential metadata. Open a remediation ticket for everything ≤ v30.0 and route it before Summer '26.
2. Stand up your DevHub-based 2GP managed package now, even if you don't ship ECA until Spring '26. The package creation and security-review timeline is the long pole.
3. Pick a Workflow-to-Flow migration cadence and put it on the sprint backlog every sprint. Don't let it get pushed by release work. The 2027 retirement window is closer than it feels.
4. Run a Connected App audit. Identify every app in the 41+ band, scope its real usage, and revoke or consolidate aggressively. Pair this with a refresh-token-revocation policy review (check CA_002).
5. Move from engagement-based remediation to continuous remediation. The 50× delta between BuildForce's median fix time and the consulting baseline is real and compounds — every quarter of delay in the switch widens the gap.
6. Subscribe to release impact alerts. Every Salesforce, HubSpot, and ServiceNow release ships breaking changes; per-release notification preferences live in the BuildForce settings and prevent the “we got blindsided by release X” pattern.
7. Benchmark yourself against the bands in this report. If your org's health-check pass rate is below 68%, you're in the lower half of the dataset. Below 60%, you're in the critical tier — prioritize remediation accordingly.

A note on sequencing

The recommendations above are listed in priority order but the sequencing matters more than the priority. Most teams will be tempted to start with the recommendation that feels most urgent — the API-version inventory or the Workflow-to-Flow migration. Don't. Start with the audit (recommendations 1 and 4) and the ECA package setup (recommendation 2). The audits surface the actual remediation queue and the package unblocks the longest-lead-time work. Once those two are in motion, recommendations 3, 5, 6, and 7 can run in parallel without colliding with each other.

One additional warning. Several teams in the dataset attempted to consolidate all four platform-shift remediations into a single multi-quarter program. The pattern consistently failed — the program scope is too large to manage as a single unit, and the dependencies between the four shifts (an ECA migration touches Connected App scope, a Workflow-to-Flow migration touches API version coverage, etc.) make the critical path impossible to predict. Run each shift as its own program with its own owner and let them coordinate at the architectural level rather than the execution level.

About the data

• Snapshot date: 2026-05-22
• Window: 2025-05-01 to 2026-05-01
• Orgs analyzed: 245 distinct production Salesforce orgs
• Minimum group size: 10 orgs per cell (smaller cells suppressed)
• Refresh cadence: Quarterly
• Aggregator code: Open-source-friendly stubs live in /next/src/lib/research/
• License: CC BY 4.0 — citation requires attribution to BuildForce Research with a backlink to https://www.buildforce.io/insights/state-of-salesforce-org-health-2026.

Questions about the methodology? Email research@buildforce.io or use the contact form below.

Frequently asked questions about this research

How many Salesforce orgs are included in this report?

245 distinct production Salesforce organizations contributed at least one completed BuildForce health-check run in the 12-month window (May 2025 – May 2026). Aggregations enforce a minimum group size of 10 orgs — any cell whose underlying group is smaller is suppressed.

What's the methodology behind the org-health pass rate?

BuildForce runs 200+ system checks across security, performance, code quality, automation, data quality, package intelligence, API versions, Connected Apps, permissions, process intelligence, field utilization, and Einstein/Agentforce AI configuration. Each run produces pass/fail outcomes per check. The org-health pass rate is the ratio of passes to total checks in the most recent completed run per org. Pass rates are averaged across orgs (not weighted by run frequency) to prevent a single heavily-monitored org from skewing the cross-org aggregate.

Is BuildForce telemetry anonymized in this report?

Yes. The aggregator never returns org IDs, user IDs, organization names, customer email addresses, or customer-supplied free-text. Queries GROUP BY industry, platform, check_category, severity, and check_id — never by individual org. Custom (user-created) check IDs are filtered out so customer-specific configuration cannot leak. A minimum-group-size of 10 orgs is enforced; smaller cells return null. See the BuildForce trust center at /trust for full data handling details.

How does BuildForce's median remediation time compare to industry baselines?

Across BuildForce-monitored orgs, the median time-to-remediation for severity=critical findings is 4.2 hours. The industry baseline — derived from published consulting-firm SLAs and customer-reported timelines — sits at 10–14 days for the same finding class. The difference reflects the difference between continuous automated remediation and engagement-based delivery.

What's an External Client App (ECA) and why is it in this report?

External Client Apps are Salesforce's next-generation replacement for Connected Apps, introduced as the recommended OAuth surface ahead of Spring '26 GA. Connected App creation will be disabled in new orgs by Spring '26. ECAs require a 2GP managed package for cross-org auth. The Spring '26 ECA migration is one of the four largest forced platform shifts of 2026, alongside the Workflow-to-Flow EOL, API versioning shifts, and Agentforce/Einstein integration changes.

Can I download a PDF version of this report?

Yes. A PDF version is available at /api/research/state-of-salesforce-org-health-2026.pdf. You can also subscribe to BuildForce Research at /contact?subject=research to receive future reports.

How often will the report be refreshed?

Quarterly. BuildForce ingests telemetry continuously, but the published research snapshot is regenerated every quarter to balance freshness against citation stability. The 'About the Data' section at the bottom of this page shows the exact snapshot date.