Your Salesforce org needs a health check when people start working around it: keeping side spreadsheets, distrusting reports, or avoiding changes because nobody is sure what will break. Those behaviours usually point to deeper issues in security, data quality, automation or licence use that a structured review can find and prioritise.
Salesforce orgs drift. Each change makes sense on its own, but after a few years of new requirements, different administrators and quick fixes, the system can become hard to understand and risky to change. Here are the signs we see most often, and what a health check involves.
People keep spreadsheets alongside Salesforce
When users maintain their own lists outside the system, it usually means Salesforce does not give them what they need, or they do not trust what it gives them. The spreadsheets are a symptom. The cause might be missing fields, slow screens, confusing page layouts or reports that do not match reality.
Reports disagree with each other
If two dashboards show different figures for the same measure, or finance and sales argue over whose numbers are right, the issue is often in the data model or the definitions behind reports. Duplicate records, inconsistent picklist values and fields that mean different things to different teams all produce figures nobody trusts.
Nobody knows why something was built
Ask your administrator why a particular field, flow or validation rule exists. If the answer is a shrug, the org has lost its documentation. That makes every change slower and riskier, because nobody can be sure what depends on what.
Automation conflicts or fails quietly
Many orgs carry layers of automation from different eras: Apex triggers, flows, and older Workflow Rules and Process Builder processes that Salesforce has retired. When several automations act on the same record, they can conflict, run in an unexpected order or fail without anyone noticing. Records that update mysteriously, or errors users dismiss without reporting, are warning signs.
Too many people have too much access
Over time, permissions accumulate. Users collect access from old roles, administrators grant broad rights to fix urgent problems, and integration users run with full system access because it was easier. A review often finds users with permission to modify all data who have no business need for it. For public sector organisations, this is a compliance issue as well as a security risk.
You are paying for licences nobody uses
Inactive users who still hold licences, add-ons bought for a project that never launched, or a higher edition than your features require all cost money every year. A licence review before renewal often pays for the rest of the health check.
Pages are slow or limits are being hit
Slow record pages, timeouts on large reports, or errors about governor limits usually point to inefficient automation, overloaded page layouts or data volumes the original design did not anticipate. These problems tend to get worse as the organisation grows.
Integrations break without anyone noticing
If a failed integration is usually discovered by a user who notices missing data, rather than by an alert, your integrations lack monitoring. Silent failures erode trust in the system faster than almost anything else.
Every release causes surprises
Salesforce delivers three major releases a year. If each one brings unexpected changes for users, nobody is reviewing release notes against your configuration or testing in a sandbox before the update reaches production.
Changes go straight into production
Building and testing directly in production is fast until it is not. Without a sandbox, a release process and a record of changes, one rushed fix can break a process the whole organisation relies on, and nobody can easily say what changed. A simple release process, with a sandbox, a test step and a change record, removes most of that risk at little cost.
What a health check covers
A good health check is structured, evidence-based and ends in a prioritised list of actions, not a long report nobody reads. It typically covers:
- Security: profiles, permission sets, sharing, integration users and high-risk permissions
- Data quality: duplicates, incomplete records, inconsistent values and unused fields
- Automation: overlapping or retired automation, error rates and order of execution
- Technical debt: custom code, test coverage, hard-coded values and unused components
- Licences: active use against licences held, and edition fit
- Integrations: error handling, monitoring and the security of connected users
- Release and change practice: sandboxes, deployment process and documentation
Each finding should be rated by risk and effort, so you can fix the high-risk, low-effort items quickly and plan the larger ones properly.
What you should get at the end
The output should be short enough to act on: a summary for decision makers, a prioritised list of findings with risk and effort ratings, and a recommended plan for the next few months. Quick fixes, such as removing excess permissions or deactivating unused users, can often be made during the review itself. Larger items, such as consolidating automation or cleaning data, become planned pieces of work with a clear scope.
How often to do one
Most organisations benefit from a full health check every year or two, and a lighter review before a major project or licence renewal. If you have just inherited an org from another provider or a departing administrator, a health check is the best first step: it tells you what you have before you change anything.
If several of these signs sound familiar, a health check will tell you which ones matter and in what order to fix them. To arrange one, or to talk through what you are seeing, call 0494 743 131.