Making Your Salesforce Org AI-Legible: The Audit That Pays Twice
How a field-level audit turns a grown-in-the-wild Salesforce org into something AI can read, trust, and work accurately — and why it pays twice.
An AI connected to your Salesforce is exactly as smart as your metadata lets it be. That one fact decides whether “ask AI about the pipeline” returns boardroom-grade answers or confident nonsense — and it’s fixable in weeks, not quarters. I recently finished doing exactly that inside a client’s production org. Here’s the purpose, the method, and what changed.
After about two years of live use, the client’s core objects carried 371 custom fields — and only 17% of them had any written description. Every answer an AI gave about that org depended on guessing what a field meant from its name alone.
Why AI struggles with a grown-in-the-wild org
Salesforce orgs grow the way cities do: nobody plans the whole thing. Fields get added for initiatives that ended two years ago, named in shorthand only the original team understood, duplicated at the wrong level because it was faster that day. None of this is anyone’s failure — it’s what live systems do.
Humans route around it with tribal knowledge. Your ops lead knows which of the four status-ish fields is the real one. AI has no tribal knowledge. It reads what the system tells it: field names, types, and the description metadata attached to each field. When the description is empty — as it was for five fields out of six here — the AI guesses. Sometimes well. Not always. And you can’t tell which from the answer.
What I set out to do
The engagement had three goals, in order:
- Establish schema truth. After years of live use, find out what actually exists — every object, every custom field, who created it, and when.
- Measure real usage. Separate the fields doing daily work from the ones quietly dead, then fix adoption and data quality where it matters.
- Make the org AI-legible. Write a clear, machine-readable description onto every field that survives — so any AI, present or future, understands the data without being briefed.
How it works — without breaking anything
The connection itself is worth a paragraph, because it’s where the trust lives. Claude connects to Salesforce over MCP (Model Context Protocol) — a standard, credentialed connection that the client’s own admin sets up and can revoke with one click. I configure it org-pinned: the connection is structurally incapable of touching any other org, and it operates read-only by default. Nothing in the client’s system changes unless we both watch it happen.
- Stand up the connection. Named, revocable, org-pinned, read-only. Verified against the org’s own identity records before any real work.
- Census the org. Every object, field counts, record volumes — a one-day map of where the complexity actually lives.
- Audit field by field. Every custom field gets two utilization rates — all-time and last-12-months — plus type, creator, and documentation status. The pair of rates is what separates “never adopted” from “recently abandoned” from “new and growing.”
- Review together. Each field gets a draft verdict from a fixed menu — keep, document, fix, merge, retire, investigate — and the client approves every single one. Before anything changes, we check where each field is used: prompts, flows, automations, reports.
- Fix and document. Retire the dead weight, standardize the picklists, and write descriptions onto everything that stays — in the exact place AI reads them.
The audit phase is zero-risk by construction: it reads, measures, and reports. If you stop there, you still own a complete field-level map of your org. Every change after that is opt-in, one approval at a time.
What the audit found
371
Custom fields audited
1 in 5
Flagged for action
100%
Now documented
0
Business disruptions
The utilization data did the arguing, so nobody had to. A block of fifteen forecasting fields hadn’t been touched on a single record created in the past year — retired. Two parallel “lifecycle stage” picklists were tracking the same thing with different answers — converged into one. Date fields living on the parent object when the real data lived on the line items — consolidated at the right level. And one field was quietly storing portal passwords in plain text; the audit caught it, and it’s gone.
A leaner org, a security hole closed, picklists that mean one thing, and a written description on every surviving field — the audit itself ran in days, not months, and nothing broke along the way.
Document the org once, and every AI you ever connect to it gets smarter on day one.
Eric Lovgren, lovgren.ai
What changes for the AI — and for the humans
| Before the audit | After | |
|---|---|---|
| How AI learns what a field means | Guesses from API names | Reads curated descriptions |
| “What’s stalled in our pipeline?” | Plausible, sometimes wrong | Accurate, grounded in the right fields |
| Building new prompts & automation | Trial and error, per project | First-pass correct against a documented schema |
| The next AI tool you adopt | Starts from zero | Inherits the documentation on day one |
And the second payoff — the reason this work pays twice — has nothing to do with AI. Documented fields mean new hires stop asking which status field is real. Reports get built on the right data the first time. Nobody creates a fifth duplicate field because the purpose of the other four is finally discoverable. The cleanup is worth doing even if you never connect an AI at all. You just won’t stop at that, because once the org is legible, the AI that reads it is suddenly worth listening to.
This is vendor-neutral infrastructure. The same field descriptions ground Anthropic’s Claude, Salesforce’s own AI tooling, and whatever you adopt in 2027. It’s a one-time investment that every future AI initiative inherits for free.
Where to start
If AI is anywhere on your roadmap, this audit is the on-ramp: fast, read-only, and you keep the full field-level workbook either way. It’s also how I work generally — on your side of the table, recommending the smallest change that gets the result. You can see how I structure engagements on the services page.