Salesforce Org Health Check vs Salesforce Security Health Check

Salesforce ships two different features with Health Check in the name. Neither of them is the thing most people mean when they ask for an org health check.

Security Health Check is a Setup page that scores security settings against a baseline and returns a percentage and a grade.

Portal Health Check is a separate, older Setup page that reports permissions and sharing for portal users, with no score at all.

Org health check is neither. There is no Setup page by that name, no score, no baseline shipped by Salesforce. The phrase describes an assessment somebody performs, and its contents vary entirely by who is performing it.

That naming collision is the source of most confusion on this subject, and it has a practical consequence. Asking for a health check gets you a number measuring thirty-one settings. Asking for an org health check gets you a document whose scope you had better define in advance, because nobody else has defined it for you.

The confusion shows up in how the topic is written about, too. Search the term and the results mix Salesforce’s own score documentation with consultancy pages offering assessments, and the most authoritative community article on performing a health check opens by excluding the org cleanup half from its own scope. Nobody is being careless. The word simply covers three different things.

Here is what each one actually contains.

Security Health Check scores thirty-one org-wide settings

Salesforce publishes the entire scored inventory, which makes the boundary unusually easy to establish.

The Health Check page in Setup groups settings by risk. Thirteen are High-Risk, ten are Medium-Risk, eight are Low-Risk, and a fourth Informational group is displayed but, by Salesforce’s own statement, does not factor into the score at all. Thirty-one scored items in total, on the default Salesforce Baseline Standard.

The full list reads as a security configuration checklist and not an org review. Session domain locking. SMS device activation. Four separate clickjack protection settings. CSRF protection on GET and on POST. The HttpOnly attribute. Hybrid behavior on security-risk file types. Maximum invalid login attempts. Expired certificates. Objects with default external access set to public. Password length, complexity, history and expiry. Login IP range enforcement. Whether administrators can log in as any user. Session timeout and logout behavior. Identity verification during MFA registration and email change. Remote site protocol security. Lockout period.

Every item on that list is a global switch. A checkbox, a dropdown or a numeric threshold that applies org-wide.

Salesforce also publishes what to do at each score band, which is more actionable than the grade label: below 34 percent, remediate high risks immediately; between 34 and 66, fix high risks short term and medium risks long term; above 67, review periodically. The score itself is available in Salesforce Classic and Lightning Experience across Professional, Enterprise, Performance, Unlimited and Developer editions, needs the View Health Check permission to read, and offers a Fix Risks control that applies baseline values without leaving the page, though Salesforce notes not every setting can be changed that way.

The Health Check score comes from a formula Salesforce does not publish

Three properties of that number matter before anyone reports it upward, and all three are documented rather than inferred.

Salesforce states that the score is calculated by a proprietary formula measuring how well settings meet the selected baseline. Category weighting is disclosed, with High-Risk counting most and Low-Risk least, but the arithmetic is not. You can see which settings fail and you can see the number, and you cannot reconstruct the path from one to the other.

The grade bands are fixed, and one omission in them is worth noticing:

There is no band between Good and Poor. The Poor label absorbs everything from 55 to 69, a fifteen-point spread, while the two bands above it cover ten points each.

The score also moves for reasons that have nothing to do with your org. Salesforce documents that new signals are introduced periodically and that your score can change when options are added to or removed from the calculation. A quarter-on-quarter decline therefore has two candidate explanations, a loosened setting or a changed signal set, and the number alone does not separate them. Relatedly, Salesforce states that new orgs start below 100 percent, so a fresh implementation begins non-compliant by default.

Finally, and most awkwardly for anyone building a governance dashboard: the score is visible on the Health Check page but not through the API. It cannot be trended automatically. Score notifications push movement to admins, and the Security Center app aggregates scores across orgs, but the raw number cannot be queried.

An org health check answers questions no setting can express

Now the other half, defined properly rather than as whatever is left over.

An org health check is an assessment of how the org has been built and how it is being used. It has no fixed contents, but a competent one covers a recognizable set of questions, none of which is a setting:

Read the access model row against the Health Check inventory and the difference becomes concrete. Health Check reports whether administrators can log in as any user. It does not report which users hold Modify All Data. Those are adjacent questions and only one of them is a setting.

Note also that the closest thing Salesforce ever shipped to a native org health check is going or gone, depending on where your org runs. Salesforce retired the Optimizer app with the Winter ’26 release for orgs on Hyperforce, and non-Hyperforce orgs lose access with Summer ’26, keeping only the hard-coded URL detection report because it matters for migration. Orgs created after 4 August 2025 never had access at all. Salesforce gives its reason plainly: the app existed to drive Lightning Experience migration, that migration largely happened, and development moved to Lightning Experience Insights. Code quality has a native tool in Salesforce Code Analyzer, which bundles eight engines including PMD and a Graph Engine. Neither covers the other’s ground, and nothing native covers adoption, data quality or accumulated debt.

Scoping and sequencing that work is the subject of a proper org assessment, and the debt it surfaces is quantified in technical debt.

Portal Health Check covers profiles but not permission sets

The second native feature is worth knowing about precisely because it covers the layer Security Health Check does not, for one narrow population.

Salesforce documents Portal Health Check as reporting on security-related portal settings, and its scope statement is specific: the reports show sensitive user permissions, object permissions and field permissions granted through profiles, together with organization-wide sharing settings and sharing rules. Five reports are included, covering administrative and user permissions, object access and field-level security, sharing organization-wide defaults, and sharing rules.

That is the identity layer, reported per profile. It is exactly what a settings score cannot reach.

Two constraints limit how far it helps. It applies to portal users and not to your internal population, and it sits under legacy service features in Salesforce’s documentation. Viewing it requires Customize Application, Manage Users and Modify All Data together.

The published blind spots matter more. Salesforce lists the access routes the reports do not include: permission sets, manual sharing, Apex managed sharing, territories, list views, groups, queues, teams, content libraries and folders. Criteria-based sharing, high-volume portal users and Self-Service portal users are also excluded.

Read the first item on that list against how modern Salesforce grants access. Portal Health Check reports permissions granted through profiles and explicitly excludes permission sets, while Salesforce has spent years steering orgs away from profiles and toward permission sets. A report built around the older mechanism will look clean in an org that does its granting the newer way.

The two differ on measurement, scope and repeatability

Side by side, the distinctions that decide which one you need:

One row deserves emphasis because it is where both instruments are weakest. Neither is automatically comparable over time. The Health Check score cannot be queried and its signal set changes underneath you. An org health check is comparable only if whoever repeats it uses the same method, which in practice means the same firm or the same documented process.

Neither instrument evaluates what an agent can reach

Agents changed the stakes here, and the reason is that both instruments miss the same layer.

An agent’s reach is set by the profile, permission sets, field-level security and sharing of the user it runs as. Health Check evaluates none of those, because none is a global setting. An org health check should evaluate them, but only if the access model was scoped into it, which is exactly the sort of thing that gets dropped when scope is implicit.

So an org can hold a 95 percent Health Check score and a clean assessment from last quarter while an agent user reads fields nobody intended. The permissions, the masking behavior and the execution context that determine this are covered in data governance for agents, and deciding who owns an agent’s permission set belongs to agent governance.

Salesforce does connect Health Check to agents in one small way. The documentation notes that Setup with Agentforce can help review your Security Health Check score, which is an assistant reading the same narrow scope rather than a widening of it.

Run both, and know which question each one answers

The two are complements, and the sequencing is straightforward.

Run Security Health Check now, because it is free, already in the org and continuously available. Fix High-Risk items first as Salesforce recommends. Upload a custom baseline, up to five are permitted, so the score measures your policy instead of a vendor default and documented exceptions become explicit rather than leaving a permanently unexplained number. Enable score notifications so movement reaches a person.

Commission an org health check when a decision depends on it: before a migration, after an acquisition, when a new platform owner inherits an org nobody has documented, when release velocity has visibly slowed, or before agents are given access to data. Define the scope in writing first, because the phrase carries no standard meaning and the access model is the section most often assumed rather than agreed.

A security review covers the identity layer both instruments tend to skip, and the standing rules that stop findings recurring belong to a governance framework, with code standards handled through Apex code review and unused configuration through org cleanup.

Teams wanting the second half done as one read of the org instead of six separate exercises can start with an org review from the AI-native delivery team, which examines data, metadata, code and configuration together.

Recap. Salesforce ships two features named Health Check and neither is an org health check. Security Health Check scores thirty-one org-wide settings through a proprietary formula, visible in Setup but not queryable, and liable to move when Salesforce changes its signals. An org health check is a category and not a product, covering configuration, code, data, access, adoption and debt at a granularity no setting reaches. Neither evaluates what an agent can read. Run the first continuously and commission the second when a decision depends on it.

Key facts

FAQ

What is the difference between a Salesforce org health check and a Security Health Check?

Security Health Check is a Salesforce Setup page that scores thirty-one org-wide security settings against a baseline. An org health check is a category of assessment with no Salesforce product behind it, covering configuration, code, data quality, access, adoption and technical debt at a granularity settings cannot express.

Is Salesforce Org Health Check a real feature?

No. Salesforce ships Security Health Check as a Setup page, but no feature called Org Health Check exists. The closest native equivalent was the Optimizer app, retired with Winter ’26 on Hyperforce orgs and with Summer ’26 elsewhere, and unavailable in any org created after 4 August 2025.

What does the Salesforce Health Check score not cover?

It evaluates only org-wide settings, so the granularity stops at the org boundary. It never examines which users hold broad permissions, what integration or agent users can reach, whether Apex enforces field-level security, guest user access, data quality, metadata volume consumed against limits, automation design or user adoption.

Can a Salesforce org score 100 percent on Health Check and still be at risk?

Yes. Every scored item is a global setting, so a perfect score is compatible with over-privileged named users, integration accounts holding broad permissions, Apex that skips access checks, unaudited guest user access, and agent users reading more data than anyone intended them to reach.

How often should each one be run?

Security Health Check is continuous and free, so review it regularly and after any release. An org health check is periodic and commissioned when a decision depends on it: before a migration, after an acquisition, when a new owner inherits the org, or before granting agents access to data.

What is Portal Health Check and how does it differ?

Portal Health Check is a separate, legacy Setup feature reporting permissions and sharing for portal users. Unlike Security Health Check it reports the identity layer, covering permissions granted through profiles, org-wide defaults and sharing rules, but it returns no score and excludes permission sets entirely.

Do AI agents show up in either health check?

Not directly. Agent reach is determined by the profile, permission sets, field-level security and sharing of the running user. Health Check evaluates no per-user settings, and an org health check only covers it if the access model was explicitly scoped into the engagement