Back to Blog

What a Salesforce Org Health Check Should Cover

•

Most orgs that need a health check got there the normal way: years of admins, a couple of partners, and a lot of fixes made under deadline. Nobody did anything crazy. Nobody can tell you what's safe to change anymore either.

Short answer: a useful Salesforce org health check reviews test coverage and code quality, data quality, the data model, automation, security and sharing, integrations, limits and technical debt, and the release process. It should end with a written report ranked by risk and effort, a prioritized roadmap, and quotes for the top fixes. It should take read-only access and a week or two, not a months-long audit. If you only get a list of tool findings, you didn't get a health check.

On one review I found 80 Flows running on a single object. Nobody had planned that. Each one was added to fix one problem, and together they made every save slow and every change risky. The follow-up work was consolidating them, refactoring the Apex trigger and the Flows so they worked together instead of against each other, and clearing out the old code and fields nobody used anymore.

The Built-In Security Health Check Is Something Else

Salesforce has a free tool in Setup called Security Health Check. It scores your security settings from 0 to 100 against a Salesforce baseline. Run it, it's worth the five minutes.

But it only looks at settings like password policies and login limits. It won't tell you whether your sharing model makes sense, whether your automation is colliding, or whether your data can be trusted. When people say "org health check" and mean a paid review, they mean the broader job below.

What It Should Cover

Tests and code quality. Salesforce requires 75% Apex coverage to deploy to production, and that number tells you less than people think. Tests can hit the lines without asserting anything. So look for failing tests, tests with no real assertions, SeeAllData=true, hardcoded IDs, and queries or DML inside loops. Check whether your Flows are tested at all, because the Apex requirement doesn't cover them.

Data quality. Duplicates, missing values on the fields your reports depend on, and fields nobody has filled in for years. This is usually the part the business feels most, even when they describe it as "the reports are wrong."

Data model. Custom objects doing what a standard object already does, fields that were added because nobody could find the old one, and relationships that make simple reports hard. Fixing these later gets expensive, so it helps to know early which ones matter.

Automation. Which Flows, triggers and older automation run on each object, and whether they step on each other. Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025. Existing ones keep running, but they're worth an inventory now, and the Migrate to Flow tool only handles the simple cases well.

Security and sharing. Org-wide defaults, the role hierarchy, sharing rules, and who holds Modify All Data or View All Data and why. Also integration users running as System Administrator, Apex running without sharing where it shouldn't, and guest user access if you have an Experience Cloud site.

Integrations. What connects to the org, under which user, with which credentials, and what happens when one fails. The common finding is an integration nobody at the company still owns, running on a login tied to someone who left.

Limits and technical debt. API usage, data and file storage, and how close your heaviest transactions get to governor limits. Plus the leftovers: unused installed packages, inactive automation, and old code nobody wants to touch.

Release process. How a change gets from a sandbox to production, and whether anyone can see who changed what. Teams shipping with change sets and no version control carry risk on every release. I've moved a number of teams from change sets to Git and CI/CD, and more on that is on the DevOps page.

Not every org needs all eight on day one. If the immediate worry is bad data and a shaky deploy, start there and add the rest once you see what comes back.

If I had to bet before looking, I'd bet on automation and technical debt. Old configuration nobody remembers adding, and Flows stacked on top of older Flows, cause more production issues than anything else I see. That's where I start.

What You Should Have at the End

The report is the product, so ask to see what it looks like before you buy. You should end up with:

  • A written report, with each finding ranked by risk and effort
  • A prioritized roadmap, so you know what to fix this month and what can wait
  • Quotes for the top fixes, so the next step has a number on it

Ranking is what makes it useful. A list of 200 issues in no order just tells you the org is messy, which you knew already.

What a Good Review Should Not Do

  • Ask for more access than it needs. Read-only admin access is enough to review an org. Nobody should be changing anything during the review.
  • Hand you raw tool output. Scanners are a fine starting point, but someone has to decide which findings matter for your business and which are noise.
  • Run forever. It's a fixed-scope review. Mine takes 1 to 2 weeks. If the scope can't be written down up front, ask why.
  • Exist only to sell a rebuild. Sometimes the right answer is to fix three things and leave the rest alone. A good report should be able to say that.

When It's Worth Doing

  • You inherited the org from a former admin or a previous partner
  • Small changes keep breaking things nobody expected
  • Users don't trust the reports
  • You're about to launch something big on top of it, like a new cloud or a first Agentforce agent
  • You're about to pick a new partner and want an outside view first

The Agentforce case matters more than it used to. An agent is only as good as what it reads, so messy data and loose sharing turn into agent problems fast. More on that in what drives Agentforce implementation cost.

Questions to Ask Before You Buy One

Plenty of Salesforce partners offer a health check, and the scope varies a lot. Compare them on these:

  • Which of the areas above are included, and which cost extra?
  • Who does the review: an architect, or someone running a tool?
  • What access do you need, and do you change anything?
  • Can I see a sample report?
  • Are findings ranked, and do I get quotes for the fixes?
  • Does the fee count toward the work if we go ahead?

My Org Health Check starts at $2,500. That covers Apex and Flow tests plus data quality, and the deeper areas are add-ons, so you only pay for what your org needs. It's quoted after a free discovery session, and the fee counts toward any project or managed services plan that starts within 30 days.

Not sure what's in your org or where to start? Book a call and I'll tell you what I'd look at first. If all you need is the free Security Health Check and a couple of cleanups, I'll say so.

Get in touch

Not Sure What's in Your Org?

Tell me what's worrying you about it and I'll tell you what I'd look at first.

Book a free 30-min scoping call