5 Signs Your Salesforce Org Needs a Health Check Before Your Next Project

An org that “mostly works” is not the same thing as an org that’s ready for your next project.

You kick off a new Salesforce project — a new Flow, a new integration, a new team onboarding onto the platform — and it takes three times longer than the estimate. Not because the new work is hard, but because every step keeps running into something already broken underneath it: a validation rule nobody remembers writing, a report that’s been wrong for eight months, a permission set that quietly blocks the exact fields the project needs. Nobody flagged any of it as an emergency, because none of it was on fire. It just made everything slower.

That’s usually the moment someone asks whether they need a Salesforce org health check. This guide covers the five signs that mean yes, and what a health check actually catches before it becomes your project’s problem.

1. Your Reports Don’t Match What the Team Actually Believes Is True

This is usually the first symptom anyone notices, because it’s the most visible. A pipeline report shows a number that doesn’t match what the sales team knows to be true. A donor report shows a household total that’s clearly inflated. Someone pulls a list of “active volunteers” and half of them haven’t logged in for two years. Individually these look like one-off reporting bugs. In practice, they’re almost always downstream of the same root causes: duplicate records inflating totals, orphaned child records with no parent, or roll-up summary fields that were never recalculated after a data import.

Notably, this kind of drift doesn’t happen all at once. It accumulates a few records at a time — a bad import here, a merge that didn’t fully clean up there — until the gap between “what the report says” and “what’s actually true” is too large to ignore. By the time someone notices, tracing it back to a single cause is usually a multi-hour investigation, not a five-minute fix.

Fix: A health check runs a structured data-integrity pass — duplicate detection across your key objects (Accounts, Contacts, Households, Opportunities), an audit of roll-up summary and formula fields against their actual source data, and a check for orphaned records with broken lookups.

2. New Automations Keep Breaking Older Ones

You build a new Flow, activate it, test it — and a completely unrelated process starts misfiring. A Process Builder that’s been running fine for two years suddenly double-fires. An email alert that used to go out once now goes out three times. This is one of the clearest signs of automation sprawl: multiple Flows, Process Builders, and legacy Workflow Rules all triggering off the same object, often in an order nobody documented, sometimes actively conflicting with each other.

Unfortunately, this problem gets exponentially worse with every automation you add, because each new one has to be reasoned about against every existing one. A team that’s been building steadily for a few years without ever consolidating almost always has automation debt they don’t fully see — until a new project forces them to touch it.

Fix: A health check maps every active automation on your most-used objects (Flow, Process Builder, Workflow Rule, Apex trigger) into a single inventory, flags conflicting or redundant logic, and identifies legacy Process Builders that should be consolidated.

3. Nobody Can Confidently Say Who Can See What

Ask your admin, “if I created a new user tomorrow with this role, what would they be able to see?” If the honest answer is “let’s find out,” that’s a sign your sharing model has outgrown anyone’s mental map of it. This happens gradually: a permission set gets cloned to solve one person’s problem, a sharing rule gets added for one exception, a profile gets edited directly instead of through a permission set — and two years later there are more permission sets than there are distinct job functions in the company.

Conversely, some orgs solve this by over-granting — giving everyone System Administrator or near-equivalent access because it’s easier than untangling the real model. That’s not actually a fix; it’s a different, riskier version of the same underlying problem, and it becomes a real liability the moment you’re dealing with donor financial data, PII, or any kind of compliance requirement.

Fix: A health check pulls your full permission set, profile, and sharing rule inventory and maps it against your actual org chart — not the theoretical one from three reorgs ago. The deliverable is usually a simplified model: fewer, more purpose-built permission sets, profiles trimmed down to genuine baseline access, and a documented sharing model someone new to the team could actually read and understand.

4. Every Small Feature Request Turns Into a Multi-Week Investigation

A stakeholder asks for something that should be simple — add a field, change a picklist, adjust an approval step — and what should be an afternoon of work turns into two weeks of “we need to understand how this will affect everything else first.” That hesitation is rational. In an org with years of undocumented customization, the honest answer to “will this break anything” really is “we don’t know until we check,” because nobody has a current map of how the pieces connect.

As a result, teams in this state tend to freeze. Legitimate, low-risk changes get shelved not because they’re hard, but because verifying they’re safe is hard. That’s a strong signal the org’s technical debt has crossed from “annoying” to “actively limiting what the business can do.”

Fix: Part of a health check is architectural documentation — a current-state map of your object model, key automations, and integrations, so “will this break anything” has a real, fast answer instead of a guess. This is also where working with a certified Salesforce administrator for the initial implementation pays off long-term: orgs that started with solid documentation practices accumulate far less of this specific problem in the first place.

5. Your Last Project Ran Significantly Over Its Estimated Timeline

This is the lagging indicator that ties the first four together. If a recent project — a new integration, a portal rollout, a reporting overhaul — took meaningfully longer than scoped, and the overrun wasn’t really about the new work itself but about everything the team kept tripping over along the way, that’s the clearest possible signal. The new project didn’t create the org debt. It just made it visible, because new work is what forces people to actually touch the older, messier parts of the org.

Importantly, this is not a project-management failure or a sign the team is bad at estimating. It’s a data point about the org, not the people. Fortunately, it’s also the easiest sign to act on, because by the time you’ve lived through one overrun project, you have concrete, specific examples of exactly where the org fought back — which makes a health check faster and more targeted than starting from scratch.

Fix: Before scoping your next project, run the health check first and use its findings to adjust the new project’s estimate honestly, rather than absorbing the same hidden costs a second time.

A 10-Minute Self-Check Before You Book Anything

You don’t need a consultant to know whether it’s worth investigating further. Run through these four checks yourself first:

Failing one of these isn’t an emergency. Failing three or four, especially alongside a recent project that ran long, is a strong case for a formal health check before you commit to the next one.

Frequently Asked Questions

How long does a Salesforce org health check actually take?

For a mid-market org (roughly 20–200 users), a thorough health check typically takes one to two weeks, covering data integrity, automation inventory, the security/sharing model, and architecture documentation. Larger or more heavily customized orgs, especially those with multiple integrations, can take three to four weeks. The output is a prioritized findings report, not just a list of problems — each issue is ranked by risk and effort to fix.

Does a health check replace a full org audit or discovery workshop?

No. A health check is narrower and faster — it’s built to answer “is this org ready for what we’re about to build,” not to re-document every business process from scratch. A full discovery workshop is broader and typically happens at the start of a larger transformation project. Many teams use a health check as the lightweight first step, then scope a deeper discovery only if the findings justify it.

Isn’t this just fixing bugs as they come up? Why do it proactively?

Fixing bugs reactively means each fix is scoped around the single symptom someone happened to notice, not the underlying pattern. A health check looks at the same categories of debt — data, automation, security, architecture — across the whole org at once, which usually surfaces three or four related issues for every one that was originally reported, and lets you fix them together instead of one expensive emergency at a time.

We’re about to start a big project — should we do the health check first or in parallel?

First, if at all possible. Running it in parallel means the new project’s team is actively building on top of unknowns that could force rework mid-project. Running it first typically adds one to two weeks to your overall timeline but produces a far more accurate estimate and fewer surprises for the actual build.

What’s the difference between a health check and just running Salesforce’s own Optimizer tool?

Salesforce Optimizer is a useful free starting point — it flags things like unused fields, layout bloat, and some automation issues automatically. However, it doesn’t evaluate your sharing model against your actual org chart, doesn’t map automation logic for conflicts, and doesn’t produce a prioritized, business-context-aware plan. Consequently, most teams use Optimizer as one input into a health check, not as a substitute for one.