The Salesforce Health Check Workbook

A Salesforce org rarely fails all at once. It degrades quietly: a workaround here, an unused field there, a report no one trusts, until adoption slips and leadership stops believing the numbers. A health check finds the rot before it costs you a re-implementation. Here is what a real one covers, and a checklist you can run yourself.

What a health check actually examines

A useful Salesforce health check goes well beyond "is it up." It looks at whether the org still fits the business, whether the data can be trusted, and whether the people who depend on it actually use it.

• Data quality: duplicates, missing required fields, stale records, and validation gaps that quietly corrupt reporting.
• Configuration health: unused fields and page layouts, overlapping automation, conflicting flows, and technical debt that slows every future change.
• Security and access: profiles, permission sets, sharing rules, and admin access that have drifted from least-privilege over time.
• Adoption: who logs in, who updates records, and where the process has quietly moved to spreadsheets.
• Reporting and forecasting: whether dashboards reflect reality and whether leadership trusts the forecast.
• Integrations: sync health across the connected stack (marketing, ERP, Gong, billing) and where data is silently failing to move.
• AI and automation readiness: whether the data and structure are clean enough to support Agentforce and automation without scaling the mess.

A do-it-yourself checklist

You can get a rough read in an afternoon. Pull these and look for the obvious red flags.

• Run a duplicate report on accounts, contacts, and leads. More than a few percent is a problem.
• Count custom fields per object and how many are actually populated. Lots of empty fields signal scope creep.
• List active flows and triggers, plus any remaining Process Builder processes and Workflow Rules, which reached end of support on December 31, 2025 and should be migrated to Flow. Multiple automations on the same object are a reliability risk.
• Check login frequency by team. Low logins among the people who should live in the CRM is an adoption alarm.
• Ask three leaders if they trust the forecast. If the answer is no, the data model or the process needs work.

How to score what you find

A finding only matters if you can act on it. As you work through the org, sort each issue by how much it hurts and how hard it is to fix. That single step turns a long, demoralizing list into a plan.

• Critical: actively corrupting data or blocking adoption right now. Duplicate accounts feeding the forecast, a broken integration silently dropping records, an automation writing bad values. Fix these first.
• High: not on fire today, but compounding. Overlapping flows, permission sprawl, and unused customizations that make every future change slower and riskier.
• Moderate: friction and clutter. Stale fields, unused reports, and layouts that confuse new users. Worth cleaning up in batches.
• Low: cosmetic or nice-to-have. Track it, but do not let it crowd out the work that moves the number.

What good actually looks like

It helps to know the target. A healthy org is not one with the most features turned on. It is one where the data is trusted, the automation is understood, and the people who depend on it use it without fighting it.

• Duplicate rates are low and there is a rule preventing new ones, not just periodic cleanup.
• Every automation on an object is documented and has a clear owner. No one is afraid to change a flow.
• Access follows least privilege, and admin rights are limited to the people who actually administer.
• The teams who should live in the CRM log in daily and update records in the system, not in side spreadsheets.
• Leadership trusts the dashboards enough to run the business off them.

From findings to a roadmap

The output of a health check should be a sequenced plan, not a 60-page audit no one reads. Group the critical and high items into a first phase with clear before-and-after measures, schedule the moderate cleanup into normal admin cycles, and decide explicitly what you are choosing not to do. The goal is momentum: a handful of fixes that rebuild trust in the system, followed by a steady cadence that keeps it healthy.

How do severity and effort combine into a schedule?

Rate each finding on effort as well as severity, then let the pair decide when it gets done. A small critical fix should never wait behind a large one.

Effort estimates can be rough. "Under a day" versus "needs a project" is often enough to sort the list.

What should you record for each finding?

Record enough that someone else could pick up the fix without repeating the review. A finding without evidence tends to be argued about rather than fixed.

• The area and object affected, such as sharing on opportunities.
• The evidence: a report name, a screenshot or a record count at the time of review.
• Severity and effort ratings, with a line explaining each.
• The proposed fix and any dependency on other fixes.
• A named owner and a target date.
• How you will confirm it worked, and the date it was checked.

Who should take part in the review?

Include the people who build the org, the people who use it and the people who rely on its numbers. An admin-only review finds configuration issues but misses the workarounds users have invented.

How often should you repeat the health check?

Run a full review once a year and a short set of checks every month. Certain events should also trigger a review outside that rhythm.

• Monthly: duplicate counts, integration error totals, inactive users holding licenses and new admin grants.
• Before a major project, such as an Agentforce rollout or a new integration.
• After an acquisition or a merger of teams onto the org.
• When your main admin or implementation partner changes.
• Ahead of a license renewal, so unused seats and products are known before you negotiate.