We Pointed Claude at a Real Salesforce Org. Here Are the 10 Things It Found in One Afternoon

Most Salesforce org assessments start the same way. A consultant gets read access, opens forty browser tabs, and spends two weeks clicking through Setup. The deliverable is a slide deck. The findings are real, but by the time you read them, the person who wrote them has moved on, and half the detail lives in their head.

We wanted to know what happens when you skip the slide deck. So we connected Claude to a real Salesforce org using CRMdig in minutes (via CRMdig Connected App, always in read-only mode), and asked it to do what a senior consultant does: find the technical debt that will hurt this team later.

The scan ran read-only, in a single afternoon. It returned 10 findings at the HIGH and CRITICAL severity floor: 2 critical, 8 high. Every finding came with the evidence behind it, the business impact in plain language, and a remediation direction.

Here is what came back, and why it matters for your org too.

Your CRM knows the answer. You just can't ask it.

That is the line we keep coming back to, and a technical debt scan is the clearest proof of it we have. The answer to "what is fragile in this org?" already exists inside your metadata. It is sitting in flow definitions, trigger bodies, permission set assignments, and Apex classes. You just can't ask the question in plain English and get a structured answer back. Until now that required a person and two weeks. Here it required a connection and an afternoon.

The two findings that would keep an admin up at night

One of them meant employee passwords were readable by anyone who could run a report. The other meant data could be sent out of the org to any address on the internet.

Reversible passwords. The scan found credentials stored as base64. Base64 is not encryption. It is encoding, fully reversible by anyone who can read the field. That is an active credential exposure, not a theoretical one. The finding included the exact storage mechanism and a remediation direction: replace the encoding with a cryptographic hash, or, if the portal that uses it has been retired, disable the auth path entirely.

A Flow input that accepts any HTTP endpoint. A second critical finding identified an invocable Apex action that accepts an arbitrary URL from any Flow and makes a callout to it. That is an unrestricted server-side request vector: a path for data to leave the org to a destination nobody reviewed. The remediation direction was specific: restrict the callout to an allowlist of Named Credentials, or delete it if nothing uses it.

Neither of these is exotic. Both are the kind of thing that gets built once, works, and is never looked at again until it becomes the headline in an incident report.

The finding that explains why nobody had caught these

One of the high-severity findings was a Flow that had grown past 600 KB.

If you have never had to debug a flow that large, here is what that number means in practice. Past roughly 250 KB, Flow Builder's interface slows to a crawl. Past 500 KB, you cannot meaningfully debug the flow inside Flow Builder at all, and Salesforce's debug logs can truncate before they reach the element that failed. This particular flow ran a customer-facing portal process used to file required compliance reports. If it failed silently in production, a user could believe a required submission went through when it never did, and the developer trying to diagnose it would be working from an incomplete log.

This is the quiet cost of technical debt. It is not just risk. It is that the org becomes hard to inspect, which means the next problem hides longer. A 600 KB flow is a place findings go to disappear.

What it checked and chose not to flag

The part of the output we did not expect to care about, but now think is the most important, is the appendix.

The scan documented a dozen categories it checked and deliberately did not flag, with the reason for each. It confirmed that every permission set in the org was queried and none granted Modify All Data. It confirmed that every trigger body was retrieved and inspected, and that only one contained embedded business logic while the rest correctly delegated to handler classes. It confirmed the org had fully migrated off Workflow Rules and Process Builder to record-triggered flows.

That last part is what separates a real assessment from a list of scary-sounding problems. A finding is only trustworthy if you know the scope of the check that produced it. "We found 10 things" means very little. "We checked these patterns, found these problems, and here is the evidence we ruled the rest out" means you can act on it. This is the difference between proof and a promise, and it is the standard we hold every CRMdig output to.

Why this works on any org, not just a messy one

You might read this and assume the findings are a story about one neglected org. They are not. Every Salesforce org accumulates this. It is a years-long accumulation of custom objects, renamed fields, deprecated workflows, and business logic that exists only in the heads of two admins. The implementation partner who built that flow in 2021 is gone. The reason a field works the way it does left with someone's predecessor.

The reason a generic AI tool cannot do this is the same reason it cannot answer any real question about your org: it does not know what your org looks like. It has never met your custom fields. CRMdig builds that knowledge first, a semantic layer of your org's structure and schema, and only then lets Claude or ChatGPT reason over it. The scan above was not the model being clever. It was the model finally being able to see.

Dig deeper

If you want to know what a read-only scan would surface in your own org, that is exactly what CRMdig is built to do. Your Salesforce record data is never stored on our servers. The connection is read-only, scoped through the CRMdig Connected App with your own permission model, and the only thing it builds is a map of your org's structure.

Your org already knows where it is fragile. You just haven't been able to ask.

Join the beta