Nobody schedules a Salesforce org health check on a calm Tuesday. It happens after a report shows the wrong number in front of leadership, after a flow fails silently for three weeks, or after the one person who understood the automation layer gives notice.
By the time it’s that obvious, the org has usually been signaling trouble for a while. Here are ten quieter signs worth paying attention to before something forces the issue.
1. Nobody Can Explain Why a Validation Rule Exists
Someone built it years ago for a reason that made sense at the time, the person who built it is gone, and now it just runs. Nobody wants to remove it in case it is load-bearing, so it stays, along with the next one, and the one after that.
2. The Org Has More Unused Custom Fields Than Active Ones
Fields get created for a project, a pilot, a one-off request, and never get cleaned up afterward. Individually, none of them cost anything. Collectively, they make every page layout harder to read and every new admin’s first week longer.
3. “Let’s Not Touch That, We Don’t Know What It Does” Gets Said Out Loud
This is the clearest sign there is. If your team is actively avoiding a part of the org rather than understanding it, that part of the org is already a liability, whether or not anything has broken yet.
4. Every Quick Change Requires Archaeology First
A one-field update turns into twenty minutes of checking what else references that field, which flows touch it, and whether a validation rule depends on it. When “quick” changes routinely aren’t, the org’s structure is fighting you.
5. Reports Show Different Numbers Depending on Who Ran Them
Different filters, different record types included, different assumptions about what “active” means, baked into reports built by different people at different times. When leadership stops trusting the numbers, it’s rarely the data that’s wrong. It’s usually the org.
6. Flows Fail Quietly, and a Customer Notices Before You Do
A flow error that doesn’t surface anywhere obvious can run broken for weeks. The first sign is often a customer complaint or a deal that stalled for no visible reason, not an error log anyone was watching.
7. Permission Problems Get “Fixed” by Widening Access
A user can’t see something they need, so someone grants broader access to make the error go away, instead of tracing why the permission was scoped that way in the first place. Repeated enough times, this is how a tightly scoped permission model quietly turns into an open one.
8. Nobody Has a Current Count of Flows, Triggers, or Automations
Not an exact number, a rough one. If the honest answer to “how many flows do we have running on this object” is “we’d have to go check,” that’s a sign the automation layer has outgrown anyone’s mental model of it.
9. Onboarding a New Admin Takes Weeks, Not Days
A new admin’s ramp time is a decent proxy for how documented an org actually is. If getting someone safely productive takes a month of shadowing and tribal knowledge instead of a clear map of what exists, the org is the bottleneck, not the admin.
10. The Person Who Understood It Best Just Left
Every org has one or two people who hold the real picture of how everything connects, usually undocumented, in their heads. When one of them leaves, the org doesn’t get worse overnight, but the next hard question takes a lot longer to answer.
Why This Happens
None of this is really anyone’s fault. Orgs grow organically over years, often through several different admins, consultants, and one-off projects, none of whom had full visibility into what came before them. Salesforce doesn’t force cleanup as you go, and there is rarely a natural moment to stop and document everything, only ever a next request to get to.
The result is an org that works, mostly, held together by a mix of institutional memory and careful avoidance of the parts nobody fully understands.
What a Health Check Actually Looks For
A proper health check is less about finding what’s broken and more about finding what’s undocumented, unused, or quietly risky. That typically means unused or duplicate fields, orphaned validation rules and flows nothing references anymore, profile and permission set sprawl, flow error rates, and how consistently record types and page layouts are actually being used versus how they were originally designed.
It usually turns up things nobody was actively worried about, because nobody knew to worry about them. A field with a generic name that turns out to be referenced by four different flows. A permission set nobody remembers creating, still assigned to a dozen users. A validation rule that silently blocks a scenario the business started supporting eighteen months ago. None of these show up as an error message. They show up as a slow accumulation of friction that everyone learns to work around instead of fixing.
None of that requires touching production. A health check is fundamentally a read exercise: understand what’s actually there before deciding what to change.
What It Costs to Put This Off
The signs above rarely cause a single dramatic failure. What they cause is a steady tax on everyone who touches the org: every new hire ramps slower, every quick change takes longer to scope, every report gets a second look before anyone trusts it in a meeting. None of that shows up as a line item, which is exactly why it’s easy to keep deferring.
The org doesn’t send a warning before the tax becomes a real incident, a botched data migration that depended on an undocumented field, a permission change that exposed something it shouldn’t have, a flow conflict that silently dropped records for weeks. Those incidents are usually traceable, after the fact, to one or two of the ten signs above having gone unaddressed for a long time.
Where AI Changes the Math
The traditional version of this work is slow because it means a person manually querying metadata, cross-referencing dependencies, and writing up findings, often over several days of a consultant’s time. An AI tool that can read an org’s metadata directly and summarize what it finds turns a multi-day audit into a single conversation, without requiring anyone to already know where to look first.
That doesn’t replace judgment about what to do with the findings. It does remove most of the friction that keeps health checks from happening until something forces them.
Cirra AI’s org-wide health audit skill reads your org’s metadata directly to surface exactly this kind of risk, unused fields, orphaned automations, permission sprawl, in a single conversation. See how a similar AI-assisted approach keeps org documentation current in our piece on Salesforce org documentation.
FAQ
How often should a Salesforce org get a health check?
There’s no universal schedule, but a yearly check is a reasonable default for an active org, with an extra one triggered by a major admin turnover, a merger, or a significant reorganization of how the business uses Salesforce.
Who should run a health check, a consultant or the in-house admin?
Either can, and the two aren’t mutually exclusive. What matters more than who runs it is whether it happens at all. AI tooling lowers the effort bar enough that an in-house admin can reasonably run one without setting aside a dedicated multi-day engagement.
Does a health check require touching production?
No. It’s a read and report exercise. Any changes that come out of the findings are a separate, deliberate step, done with the same care as any other configuration change.
What’s the difference between a health check and cleaning up technical debt?
A health check identifies what’s there and what’s risky. Cleanup is the follow-up work of actually fixing it. Treating them as one project tends to stall; treating the health check as a fast, standalone first step makes the cleanup that follows much easier to scope.
Can a health check be done without disrupting day-to-day admin work?
Yes. Because it’s a read-only exercise against metadata that already exists, it runs alongside normal admin work rather than blocking it. The disruption, if any, comes later, in deciding what to do with the findings, not in gathering them.
What should happen right after a health check finishes?
A prioritized list, not a to-do-everything list. Some findings are cosmetic, some are genuinely risky, and treating them all as equally urgent is how cleanup projects stall before they start. Sorting by actual risk, permission sprawl and silent flow failures usually outrank an unused field, is what makes the findings actionable instead of just alarming.
The Takeaway
If two or three of the signs above sound familiar, that’s usually enough reason to run a health check before something forces the issue. Understanding what’s actually in an org, before making the next change to it, is the difference between building on a clear foundation and adding one more thing nobody will be able to explain in two years.
