The Most Hated Admin Work Isn't Hard. It's Invisible.

Salesforce Ben just published the results of their 2026 Admin Survey, and one number stands out. When admins were asked what would most help reduce technical debt, the top answer, at 62.17%, was dedicated time for cleanup and refactoring.

It is a reasonable ask. Technical debt ranked as the single hardest part of the job in the same survey, at 56.3%. Over half of admins said too much is expected of them. Nearly one in five works alone.

But here is the uncomfortable part. Most admins who finally get a cleanup sprint don't spend it cleaning. They spend it finding out what's there.

Two kinds of hated work

The survey and the conversation around it surfaced the tasks admins hate most. They split into two piles, and it is worth being honest about which one we can help with.

The first pile is grunt work. Merging duplicates. Permission requests. The Slack message that says Salesforce is broken with no screenshot attached. One admin in the article put it plainly: "Users think we somehow just know what's going on in the org at all times." No scan fixes that pile. It is volume, and it needs process and boundaries, not tooling.

The second pile is investigation. One admin described chasing down a flow that stopped working because someone renamed a field three months earlier and never documented it. The survey's top three Flow Builder challenges were debugging errors, understanding complex logic, and maintainability. Notice what those have in common. None of them is building. All of them are figuring out what already exists.

That second pile is the one that eats cleanup time. And it is the one a scan collapses.

What discovery actually costs

We connected Claude to two real Salesforce orgs using CRMdig, read-only through a Connected App, and asked it to map what was there. Here is what the investigation pile looks like in practice.

In one org, the scan found an invocable Apex action that accepts an arbitrary URL from any flow and makes a callout to it. The remediation was simple: restrict it to an allowlist of Named Credentials, or delete it if nothing uses it. The scan confirmed nothing uses it. Zero active flow references. Now do that by hand. Confirming that a component has zero references means opening every flow in the org and checking. That is not a hard task. It is an invisible one, and it is exactly why dead code survives for years.

In the same org, a flow running a customer-facing compliance portal had grown past 600 KB. Past roughly 250 KB, Flow Builder slows down. Past 500 KB, you can no longer meaningfully debug, and the logs truncate. Nobody decided to build a flow that can't be debugged. It accumulated. And every cleanup conversation about it starts with a question nobody can answer quickly: what does this thing actually do?

In the second org, a single field requirement was enforced in three separate places, three generations of automation, all still active and still firing. An admin planning to change that requirement safely would need to already know all three exist. The org's own "where is this used" tooling shows where the field appears, not which automations quietly enforce the same rule.

None of these fixes is difficult. The discovery is what's expensive. You cannot refactor what you cannot see, and most orgs have no map.

A map on day one

This is also the honest answer to the AI tension the Salesforce Ben piece raises. AI tools that help admins build faster can quietly raise expectations: now you should ship more, sooner. A scan does the opposite. It does not build anything. It hands you the map, so the cleanup sprint you fought for gets spent fixing instead of spelunking. The judgment stays yours. The archaeology doesn't have to.

CRMdig works because it builds that map first. It indexes your org's structure and schema into a semantic layer, then lets Claude or ChatGPT reason over it. The connection is read-only and scoped through a Connected App with your own permission model. Your Salesforce record data is never stored on our servers. What gets stored is the metadata, which is exactly the thing you need to answer "what is in here, and what depends on what?"

Dig deeper

If you get your cleanup sprint, three questions worth asking your org on day one:

1. Which Apex classes and components have zero active references anywhere in the org?

2. Do any flows exceed 500 KB, the point past which they can no longer be meaningfully debugged?

3. For the field I'm about to change, list every flow, validation rule, and Apex class that enforces a rule on it.

If answering those would take you a week of clicking, that week is your cleanup sprint disappearing into discovery. Your org already knows. You just haven't been able to ask it.

Join the Beta Program