Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

Short answer: Security Health Check scores your org’s security settings against a baseline and takes a minute to read. Salesforce Optimizer reports on configuration debt and takes an afternoon to act on. Both are free, both are underused, and neither reads your Apex, which is where the problems they miss actually live.

Security Health Check

Setup, Security, Health Check. It compares your settings against the Salesforce Baseline Standard and gives a percentage, with each setting marked as meeting the standard or not.

What it covers: password policies, session settings, certificate and key management, login IP ranges, sharing settings at the org-wide level, and a set of high-risk toggles.

What the score means is less than it looks. It measures settings against one opinionated baseline, so a deliberate deviation shows as a failure. An org at 78 per cent with three documented exceptions is in better shape than one at 95 per cent where nobody has looked at what the settings are for.

Two genuinely useful things it does. You can upload a custom baseline, which turns it from a generic score into a check against your own standard. And the per-setting view tells you what the current value is against the recommended one, which is faster than opening eight Setup pages.

Salesforce Optimizer

Optimizer runs as an app in the org and produces a report on configuration you are likely carrying without benefit. The sections worth acting on:

  • Unused fields and objects. Fields with no data, on no layout, in no report. Deleting these is the cheapest debt reduction available.
  • Too many fields on an object. Correlated with page load time and with nobody knowing which field to use.
  • Validation rules and workflow rules that are inactive or duplicated.
  • Profiles with no users, which accumulate after every reorganisation.
  • Sharing rules approaching the limit, which is a real ceiling people meet unexpectedly.
  • Apex API versions that are old enough to be at risk of retirement.

Its blind spot is that it counts things rather than judging them. A hundred fields on Account might be a mess or might be a genuinely complex business. The report is a list of questions, not a list of faults.

What neither one tells you

This is the important part, because reading a clean report as a clean bill of health is the failure mode:

  • Nothing about your Apex. No sharing keywords, no @AuraEnabled exposure, no injection risk, no test quality. The layer where security incidents actually originate, described in security in practice, is invisible to both.
  • Nothing about your integrations. An integration user with System Administrator passes every check.
  • Nothing about whether automation is correct, only that it exists.
  • Nothing about data quality.

A sensible cadence

Health Check before every release, because it is a minute and settings drift. Optimizer quarterly, because acting on it takes real time and the findings do not change weekly.

Treat the Optimizer report as a backlog rather than a checklist. Pick the three items with the clearest benefit, do those, and let the rest wait for next quarter. A team that tries to clear the whole report stops running it.

The findings worth doing first

From experience with what actually pays back:

  1. Unused custom fields. Deleting is reversible for 15 days and reduces page load, report clutter and confusion.
  2. Inactive validation rules and flows. Either activate them or delete them. A deactivated rule sitting for two years is a decision nobody made.
  3. Old Apex API versions. These become urgent when a version is retired, and by then it is a deadline rather than a task.
  4. Profiles with no users. Five minutes each and they make every permission audit harder while they exist.

Frequently asked

Does Optimizer change anything? No, it only reports. Everything it suggests is yours to do.

Can I run either in a sandbox? Yes, and the results differ from production because the configuration and data differ. Run both where the decisions apply, which is production.

Is there an API for these? Health Check has limited programmatic access. For a repeatable audit you own, a metadata retrieve plus your own queries is more flexible and is the approach that scales to what neither tool covers.