CodiotFree estimate
Salesforce

Salesforce health check: 15 things we audit first

Urvish··4 min read

A Salesforce health check is a structured review of your org against how the business actually works today, and it almost always finds more than anyone expects. Orgs drift. Fields get added for a campaign that ended two years ago, automation stacks up in layers, and permissions accumulate quietly until nobody can say who can see what. A health check turns that drift into a prioritized list you can actually act on.

Here is what we look at first, and why each one matters.

Data and the data model

  1. Duplicate and stale records. Duplicates quietly corrupt every report built on top of them. We measure the duplicate rate and check whether matching rules exist at all.
  2. Unused fields. Fields with almost no populated values are usually abandoned requirements. Each one adds page clutter and slows down every admin who has to reason about the object.
  3. Data model fit. Whether objects and relationships still match how the business is organized, or whether teams have started overloading one object to mean several things.
  4. Required-field discipline. Fields marked required in the UI but not enforced at the data layer, which is how partially valid records get in through integrations.

Automation

  1. Overlapping automation. Workflow rules, Process Builder, and Flow doing similar jobs on the same object is the most common source of unpredictable behaviour we find.
  2. Order of execution problems. Automation that fires in an order nobody designed, producing results that only reproduce sometimes.
  3. Error handling. Whether failed automation surfaces to a human or fails silently. Silent failure is far more expensive than a visible error.
  4. Scheduled jobs. Jobs still running against processes that were retired, consuming limits for nothing.

Custom code

  1. Apex without meaningful tests. Coverage that exists to pass deployment rather than to prove behaviour is one of the clearest signals of accumulated risk.
  2. Hardcoded IDs. Record type or user IDs baked into code, which breaks the moment you deploy to another environment.
  3. Governor limit exposure. Queries and loops that work at current data volume and fail at two or three times that volume.
  4. Code that should have been configuration. Apex doing work that Flow now handles natively, which costs more to maintain forever.

Security, sharing, and access

  1. Profiles and permission sets. Whether access is granted through a maintainable permission-set model or through years of one-off profile edits.
  2. Sharing model coherence. Org-wide defaults, roles, and sharing rules that contradict each other, usually resolved by granting more access than intended.
  3. Integration users and API access. What connected apps and integration users can actually reach, and whether any of them still need it.

What a health check should produce

The output is not a list of complaints. It is a prioritized backlog: each finding with a severity, the business risk it creates, the rough effort to fix, and a recommended sequence. Some items are an hour of admin work. Some are a project. The value is knowing which is which before you commit a budget.

A good review also separates what is genuinely broken from what is merely unfashionable. Plenty of older automation works perfectly well, and replacing it because it is old is a poor use of money. The configuration versus customization distinction matters here: the goal is the cheapest maintainable version of what the business needs, not the newest.

When to run one

Run a health check before a major rollout, after a merger or reorganisation, when a new admin or partner takes over, or when the symptoms in the FAQ below start showing up together. It is also the sensible first step before committing to a large build, because the cost of a new project is heavily influenced by the state of the org it lands in, as anyone who has priced a Salesforce implementation knows.

If your org has drifted from how the business runs, an audit is the cheapest way to find out how far. Our Salesforce development work usually starts exactly here, with a review rather than a proposal.

FAQ

What is a Salesforce health check?
A Salesforce health check is a structured review of your org against how the business actually operates today. It covers data quality, automation, custom code, security and sharing, reporting, and adoption, and produces a prioritized list of what to fix, in what order, and roughly what each item costs in effort. It is a diagnosis, not a rebuild.
How often should you audit a Salesforce org?
Once a year is a reasonable baseline for a stable org, and every six months if you are shipping changes continuously, have multiple teams in the same org, or recently went through a merger or a big rollout. Salesforce also ships three platform releases a year, so a light release-readiness check each cycle is worth doing regardless.
What are the signs your Salesforce org needs a health check?
Users exporting to spreadsheets to get their work done, reports that different teams disagree about, automation nobody wants to touch, admins afraid to deploy, slow page loads or governor-limit errors, and permissions granted ad hoc over the years. Any two of those together usually mean the org has drifted from the business.
Start

Got an idea? Let's build it.

Tell us what you're making. We'll reply within two business days with an honest take on scope, timeline, and cost.

Get a free estimate