Salesforce health check: what a real one finds

This page is about what a health check is, what it should examine, what the written output should contain, and how to tell a genuine review from a two hour meeting that ends in a proposal for project work. If you are buying one, that last part matters more than the price.

What a health check actually is, and what it is not

A health check is a diagnosis. Somebody qualified looks at the org as it stands today and tells you, in writing, what is healthy, what is fragile, and what is already costing you money or time. It is not a rebuild, it is not a roadmap, and it is not a sales process with a findings section bolted on.

Three things get confused with it constantly:

• A health check answers one question: what state is this org in? It should be possible to finish one without selling a single project afterwards.
• An audit is narrower and more formal. It usually means compliance or security evidence against a standard, with a paper trail an auditor can sign.
• A review of a specific build is a design critique: you have already decided to change something and want the plan checked before you spend money on it.

An org with a competent internal admin and a stable release history might not need one for years. An org that has had three consultants in two years, or one that has never been looked at since implementation, usually finds enough in the first morning to pay for the whole exercise.

The six areas a health check has to examine

Scopes vary, and they should. But a check that skips any of these six is a partial picture, and the gaps tend to be exactly where the expensive surprises live.

1. Data model and accumulated technical debt

Duplicate objects and fields that mean the same thing, fields nobody has reported on in two years, lookup relationships that point nowhere useful, and record types that multiply because nobody wanted to have the conversation about process. This is unglamorous work and it is where most of the cost of the last five years is hiding. Every field has a maintenance cost: it appears in page layouts, in reports, in integrations and in every future migration.

2. Automation, including the flows nobody remembers

Most orgs now carry a mix of Flow, older workflow rules that were never migrated, process builder left running in parallel, and validation rules layered on top of each other. The questions are simple and rarely documented: what fires on this object, in what order, and what happens when two of them disagree? A flow that runs on every edit of a high volume object, with a loop and a query inside it, is a performance problem that has not happened yet.

3. Access, sharing and security

Who can see what, and why. Profiles versus permission sets, the handful of users with Modify All Data, guest user access on anything public facing, connected apps with wide scopes that were authorised during a pilot, and the sharing rules that were widened to solve one complaint. Security posture decays slowly and silently, because nothing breaks when access is too broad.

4. Limits, performance and storage

API request consumption against allocation, file and data storage growth, the big objects and report types that make list views slow, and any synchronous callout sitting inside a trigger path. Limits are the part of Salesforce that behaves like a utility bill: predictable until it is not, and then it is a production incident with a support case attached.

5. Integrations and everything outside the org

Every integration has three questions attached to it: what does it do, who owns it, and what happens when it fails quietly? In practice, most orgs can name the integrations and cannot answer the second or third. An ERP feed that has been failing on one record type for a month looks exactly like a working feed until somebody reconciles the numbers.

6. Reporting, adoption and the support you are paying for

Which reports and dashboards are actually opened, which are politely ignored, where users keep work in spreadsheets because the system does not answer their question, and what the current support arrangement is doing with its hours. Adoption is the least technical area and the one most likely to explain why a well built org still feels like admin.

What the findings report should contain

Ask to see a sample report before you buy, redacted is fine. A real one has a shape.

• A findings register, not an essay. Each item gets an identifier, a description in plain language, the object or area it touches, and the evidence that produced it.
• Severity tied to consequence. Not high, medium, low in the abstract, but what breaks, who is affected, and how soon. A missing field description is trivia. A guest user with write access is not.
• Effort and impact, separately. Some findings are two hours of work with a large payback. Those go first, and a report that does not separate them from the six week items is not helping you decide anything.
• The things that are fine. A credible review says what is working and should be left alone, especially where somebody has already proposed changing it.
• An explicit "nothing to fix here" option. If the honest answer is that the org is in reasonable shape, that should be a normal and respectable outcome, not a lost sale.
• A named person to talk it through with. A PDF with no conversation is a lead magnet, not a diagnosis.

How to tell a real health check from a sales pitch

The tell is almost never the document. It is the sequence.

• Who does the work. If the person presenting the findings is not the person who opened the org, the findings were assembled by somebody who has not seen the detail. Ask who will do it, and what else they are working on that week.
• How long it takes. A serious pass over a mid-sized org with custom automation is measured in days, not hours. Anything under half a day is a configuration export with commentary.
• Whether they ask for sandbox access. Reading metadata tells you what exists. Opening it tells you what happens when it runs. A provider who will not test anything is guessing.
• Whether the findings criticise anything they built. Every org has somebody's fingerprints on it. A review that finds nothing wrong with the current partner or the original build is not looking.
• Whether the remediation list is one big project. The first recommendation should be a small set of cheap fixes, not a platform reimplementation with a phase one.
• Whether you can keep the documentation. The findings, the object inventory and the automation map are yours. If they only exist inside the provider's tooling, you have rented a diagnosis.

A thirty minute self-check you can run today

None of this replaces a proper review. All of it will tell you whether you need one, and it will make you a much harder person to sell to.

1. Open Setup and list every active flow on your two busiest objects. Note the last modified date on each. Anything nobody can explain is a finding.
2. Check API request consumption for the last seven days against your allocation, and look for the one integration consuming most of it.
3. List the users with Modify All Data and the users with a system administrator profile. If the list is longer than the number of people who actually administer the system, that is a finding.
4. Find the reports and dashboards nobody has opened in ninety days. They are maintenance you are paying for and not using.
5. Ask two users what they keep in spreadsheets. Then find out why the system does not answer that question.
6. Ask who owns each integration, by name. "The vendor" is not an owner.
7. Check the last two release windows: was anything tested in a sandbox before it hit production?

If three or more of those are uncomfortable, a structured check will find more. If all seven are clean and documented, you probably already know your org well.

When to book one

Health checks are worth most at specific moments, and paying for one at the wrong moment wastes the money.

• Before a major project. Cheapest possible time, because the findings change the project scope rather than arriving after it.
• When the person who built it leaves. Knowledge walks out with people, and a review is the fastest way to recover what was never written down.
• Before you sign or renew a support arrangement. You cannot negotiate scope or price against an org you do not understand, and a second opinion on an existing retainer is usually worth the fee on its own.
• After two or three releases have passed without testing. Release debt compounds, and the fixes get more expensive each quarter.
• Before a licence renewal or a move to a new edition. Feature comparison is easy. Knowing which of your customisations a standard feature would now replace is the part that saves money.

What it should not be is an annual ritual performed because a contract says so, with the same findings copy-pasted from last year. If the report has not changed, either the org has not changed, which is a finding in itself, or nobody read the last one.

Where this fits with everything else

If you want to know what the platform should cost you in total, including licences and the ongoing line items people forget, what Salesforce actually costs an Australian business covers the shape of the spend. If the org needs reshaping rather than diagnosing, that is Salesforce consulting work. If you already pay somebody to look after it, what a managed service should actually include is the buyer's checklist for that arrangement, and a health check is a fair way to test whether you are getting it.

One more overlap worth naming. A lot of what a health check finds is not a Salesforce problem at all: triage, first draft responses, status updates and data entry between systems. That work is usually better handled by AI automation than by another custom object, and it is worth knowing which of the two you are actually buying before anybody scopes a project.

Questions we get asked about Salesforce health checks

How long does a Salesforce health check take?

For a mid-sized org with custom automation and a few integrations, plan on one to three working days of analysis, with the report a few days after that. Simple, lightly customised orgs are faster. Orgs with years of layered automation, or custom code somebody else wrote, take longer because reading is not enough and behaviour has to be tested.

Do we have to give you production access?

Not to production data. A sandbox with a recent refresh is usually the right place to learn how the org behaves, plus a read only look at metadata and limits in production. Any provider who needs write access to production to perform a diagnosis is describing a change project, not a review.

What is the difference between a health check and an audit?

An audit produces evidence against a standard, usually for compliance, security or a board. A health check produces a prioritised view of what is fragile and what it will cost to fix. They overlap in method and differ in audience: one is written for an auditor, the other for whoever has to decide what gets funded next quarter.

Will it just tell us to rebuild everything?

It should not, and a review that does is usually selling implementation. Rebuilds are occasionally correct, and when they are, the honest recommendation starts with a small number of cheap fixes that reduce risk immediately and buy time. If the only finding is "start again", ask what the cheapest version of the next six months looks like. The answer tells you a lot about who you are talking to.

---

Start with the free review, not the project

You do not need to commit to remediation to find out where you stand. The Salesforce review looks at the org, the automation, the release history and the support you are currently paying for, and tells you plainly what is healthy, what is fragile, and what the next twelve months should cost. If your current arrangement is fine, that is a legitimate outcome and we will say so.