What we look at when we run a Salesforce health check

I’ve been doing Salesforce work for about a decade now, and there’s a particular kind of phone call I get several times a year. Someone new has taken over a Salesforce org, usually because of a reorg, an acquisition, or a predecessor who left, and they want to know what they’re dealing with before they touch anything. Sometimes it’s the opposite: someone has run the same org for years and has a nagging feeling that something underneath the hood isn’t right, they just can’t say what.

Both calls end the same way. I tell them we need to look at the org properly before anyone can say anything useful, and that used to mean a week of manual digging through Setup, running SOQL queries, and building a spreadsheet by hand. It was slow, it was inconsistent from consultant to consultant, and honestly, it was the part of the job I liked least.

That’s the reason we built the Salesforce Org Health Optimizer.

What the Salesforce Health Optimizer checks

I get asked this a lot, so let me just lay it out. The tool connects to a client’s org with a read only API user (nothing gets written, nothing gets changed) and works through twelve areas:

  1. Security posture: org wide defaults, connected apps, guest user profiles, MFA enforcement, and whether the sharing model matches what the business needs

  2. Governor limits: where the org sits against Salesforce’s platform ceilings, and which ones are trending toward trouble

  3. User adoption: who’s logging in, who isn’t, and how many licenses are going unused

  4. License and entitlement spend: this is the one that tends to surprise people the most, more on that below

  5. Automation health: flows, legacy workflow rules and process builders that Salesforce is retiring, and how much of the org’s logic lives in code nobody’s looked at in years

  6. Apex codebase: class count, trigger count, and which classes are sitting on ancient API versions

  7. Data quality: field completeness, duplicate records, and how stale the pipeline is

  8. Business process compliance: lead response times, pipeline hygiene, case backlog

  9. Cloud adoption: this is newer. We check what capability a client is paying for versus what’s sitting on the shelf unused

  10. Installed packages: every managed package in the org, and whether any of them have been deprecated by the publisher without anyone noticing

  11. Storage and growth: current consumption and how fast it’s climbing

  12. A prioritized roadmap: everything above gets translated into a ranked list, immediate, 30 days, 60 days, 90 days

That’s the whole thing, front to back, in about 2 or 3 hours of processing time once we have API access. This saves many hours a week of a consultant’s and the client’s time.

Why the Salesforce Health Optimizer pays for itself

Here’s the section I most want to spend time on, because it’s the part that tends to get glossed over when people talk about org health checks. This isn’t just a diagnostic exercise. Every one of these reports we’ve run has surfaced real value that was already paid for and sitting unused.

Take a recent example I encountered: the license utilization page showed fifty Identity licenses provisioned, and none of them were active yet.

Fifty licenses, sitting there, already part of the agreement, not doing anything for anyone. Instead of being a cost problem, it was an adoption problem, and it was the good kind of problem to have to have. The fix didn’t require a single new purchase order, but it did require awareness. Standing up single sign-on for the workforce puts that capacity to work immediately. The entitlement was already there, though nobody had gotten around to using it.

The same report showed eighteen Salesforce Platform licenses with only five actually being used day to day. There were thirteen seats of ready capacity, sitting idle, that could onboard new users into limited-access or department-specific roles tomorrow with no procurement cycle at all. Meanwhile the core Salesforce license pool was at ninety percent, clearly earning its keep. That kind of imbalance is invisible until someone lays the numbers side by side, and it’s exactly the kind of thing a client’s own team is too close to the day to day to spot on their own.

This is the actual value proposition. It’s not “here’s a list of things wrong with your org.” It’s “here’s capacity you’re already paying for that isn’t delivering value yet, and here’s how to point it at something.” I’ve sat across the table from operations leaders who cared a great deal more about turning on that unused Identity capacity than about the technical debt sitting in the Apex codebase, and that’s a completely reasonable thing to prioritize, because both matter. But showing someone value they already own and aren’t using tends to open the door to the rest of the roadmap.

Data Quality

I’ll be honest, I expected this to be less common than it turned out to be. Quiet a lot of the orgs we’ve run this against have an Industry field on Account sitting at or near zero percent completion.

The pattern usually tells the same story. Someone most likely added the field years ago with good intentions, maybe even ran an enrichment project once, and then the org grew and the process didn’t. Nobody enforced it at data entry, nobody built a validation rule, and eight thousand records later it’s just... empty. Segmentation reports don’t work. Marketing can’t target by vertical. Sales leadership asks “which industries are we strongest in” and the honest answer is “we don’t know, because we never captured it.”

Because nothing breaks, nothing shows up to notify the team there is an incident. That’s why it survives for years without getting fixed, and why it’s worth putting in front of someone with a chart to show the value (or lack thereof) in the numbers.

What happens after the report lands

The last page of every report is a prioritized roadmap, which ranks each needed change with a timeline attached to each item. I’ve learned the hard way that a findings document without a ranking is just guilt on paper, because nobody has time to act on forty equally weighted bullet points. Instead, when they are given three things that need to happen within the week, and then are told what can happen within the month and within the quarter, they’re ready to take the small steps to get to the goal.

For an internal team, this becomes the thing they work off of for the next quarter. For us, it’s usually the start of the next phase of the engagement, because once someone can see fifty licenses of ready capacity sitting untapped and a system administrator count that’s twice what it should be, the conversation about what to do next tends to have already made itself.

Who is the Salesforce Health Optimizer for?

There are three kinds of people who ask Eigen X to run a Salesforce health check. The first is the person who just inherited the org and needs the lay of the land before they make any decisions they’ll have to defend later. The second is the person who’s been running the org for years and wants a second set of eyes before signing off on something big like a platform migration, an Agentforce rollout, or a merger of two orgs. Finally, the third person is the person who can tell something is off but doesn’t have the vocabulary for it yet.

That last group is the one I find most rewarding to work with, because the report gives them language for something they already sensed and just couldn’t articulate to their own leadership.

What the Salesforce Org Health Optimizer could do for your organization

If any of that sounds like where you are with your Salesforce Org, there’s more detail on how we run the assessment and what the engagement looks like at eigenx.com/salesforce-org-health-optimizer, or you can contact Eigen X, and we will walk you through a health check together.

Previous
Previous

LLM Conversation Dynamics

Next
Next

Migrating to the New Agentforce Builder: What to Know Before You Upgrade