A 100% Salesforce Health Check Score Doesn't Mean Your Org Is Healthy

Run a Salesforce Health Check on almost any production org - Setup → Health Check - and there's a real chance it comes back at 100, or close to it. That score is genuine - it means the org's security settings meet Salesforce's own baseline. It says nothing about whether a second person could explain why last quarter's biggest Flow still exists, whether the data model matches how the business actually runs today, or whether an integration that 'occasionally glitches' is a real bug or an undecided ownership question - exactly the kind of gap a Salesforce Health & Roadmap review exists to catch precisely because a clean score doesn't catch it. Confusing 'passed the native check' with 'the org is fine' is an easy mistake, and an expensive one to make right before a budget conversation, a partner handover, or an Agentforce rollout.

The short answer

In brief: a Salesforce health check can mean three genuinely different things - the free native Security Health Check score, a scanning tool like the open-source Org Check (Salesforce's own replacement for the now-retired Optimizer app), or a senior-led architecture review that actually interprets what those tools surface. Run the native check for free, always - there's no reason not to. Add a scanning tool once more than one person touches the org, to catch the config bloat and unused metadata a security score was never built to see. Pay for a senior-led review when a decision - a budget request, a partner change, an AI rollout - depends on judgment a tool can't produce. If what a review turns up is one well-understood problem rather than a broad unknown, a Fix Sprint is usually the faster way to close it than a full review-and-fix cycle. The tools and the review aren't competing options; they answer different questions, and most orgs need the first two running continuously and the third only when something expensive is actually being decided.

Three different things people call a Salesforce health check

The word gets used loosely enough that it's worth being precise about what each option actually checks, because comparing a free tool against a paid engagement on price alone means comparing things that don't do the same job.

• The native Security Health Check (Setup → Health Check) - free, built into every org, scores your security settings against Salesforce's Baseline Standard or a custom baseline you define yourself.
• A scanning tool like Org Check, the free, open-source Salesforce Labs app that replaced Optimizer after Salesforce retired it, or a paid AppExchange product such as Metazoa Snapshot or Elements.cloud - these surface metadata bloat, unused fields, and configuration sprawl a security score doesn't cover.
• A senior-led architecture review - a person, not a script, reading what those tools surface against the decisions your org is actually facing, then prioritising what to fix first. This is the only one of the three that produces judgment rather than a list.

What the native score actually measures - and drifts on

The Health Check score weighs findings across four risk categories - High, Medium, Low, and Informational - with High-risk settings counting the most and Informational findings not affecting the score at all. It's checking configuration against a standard, not behaviour: password policy, session settings, and similar controls, compared against Salesforce's baseline or a stricter one you set yourself, such as requiring 15-character passwords instead of 8. Two things make a clean score less reassuring than it looks. Not every flagged setting can be fixed with the one-click 'Fix Risks' button - some still need a manual edit, which is easy to skip when the dashboard already looks green everywhere else. And settings drift: someone disables a restriction for a vendor demo or an urgent integration test, forgets to re-enable it, and the score doesn't reflect that until the next scheduled look. A score is a snapshot, not a guarantee, and it was never scoped to cover automation health, data quality, or user adoption in the first place - which is why Salesforce's own Well-Architected framework treats security settings as one input toward a broader Trusted, Easy, and Adaptable view of an org, not a stand-in for it.

Native tools, a scanning tool, or a senior-led review

What a clean scan still misses

A scanning tool can tell you an object has 40 active Flows and dozens of unused fields. It can't tell you whether a specific Flow enforces a business rule that still matters or was built for a process that ended two years ago - that needs a person who can read the criteria and ask around, which is exactly the gap that turns into single-admin risk once nobody's left to ask. It can flag that a field gets written to by two systems; it can't tell you which one is supposed to win, which is the same ownership decision that gets misdiagnosed as a flaky integration far more often than it gets named correctly. None of that is a knock on the tooling - a scanner is built to enumerate, not to judge, and treating a clean dashboard as permission to stop looking is how both problems above sat undiagnosed for months in the first place.

Why this matters more once AI is on the table

A native security score has never checked data quality, and that gap used to be tolerable - a stale or duplicated record sat there being merely annoying until someone noticed. Handing that same data to an Agentforce agent changes what the gap costs: an agent grounded in wrong or duplicate records doesn't get more cautious, it gets more efficient at repeating the mistake at volume, a risk we've covered from the access-control side in Salesforce in Claude's permission model. None of the three assessment options above was designed around that specific question - which fields could an AI agent read or write, and do you actually trust what's in them - which is exactly the kind of question that needs a person to ask deliberately rather than a scan to answer by default.

A few questions worth asking before you run anything

Is Org Check the same thing as a health check?

No - it's a scanning tool, not a review. Org Check, Salesforce's free open-source replacement for the retired Optimizer app, is genuinely useful for surfacing unused fields, metadata bloat, and configuration sprawl, and there's no reason not to run it alongside the native Security Health Check. Neither one tells you which of its findings actually matters for your specific org, or what to fix first - that's the part a scan was never built to do.

How often should we actually run a health check?

Run the native Security Health Check and a scanning tool like Org Check on a recurring basis - monthly is reasonable, since settings drift and metadata accumulates continuously, not on a schedule that waits for an annual review. A senior-led review is different: it's tied to a decision, not a calendar - before a budget commitment, a partner change, or a major initiative like an Agentforce rollout, rather than a fixed yearly ritual regardless of what's actually changed.

Can an internal team do the judgment part itself, without outside help?

Sometimes, and it's worth being honest about when. A team with a genuinely senior admin or architect, room to step back from day-to-day tickets, and no reason to doubt their own objectivity about their own past decisions can do a credible version of this internally. The harder case is an org that's outgrown one person's full picture, or where the review needs to be defensible to someone who didn't build it - a partner handover, a board, an auditor. That's usually where outside judgment earns its cost, not because internal people aren't capable, but because nobody can fully audit their own blind spots. You can see the shape of engagements this looks like in practice on our case studies page.

The bottom line

None of this is an argument against the free tools - run the native Security Health Check and a scanner like Org Check regardless of what else you do; there's no real reason not to. The mistake is treating a clean result from either one as proof there's nothing left to check, when both were built to enumerate specific, narrow things rather than judge whether your org is actually fine for what you're about to do with it. If you can't currently say which row of the table above describes your situation, that uncertainty is what a Salesforce Health & Roadmap assessment is built to resolve, led directly by a senior architect rather than run off a checklist. Talk to us before assuming a green dashboard means you're done.