A cybersecurity SaaS company handed us a Salesforce org that ran their entire revenue engine — lead routing, attribution, territory assignment — with no sandbox, no documentation, and a routing stack that a previous team had left mid-refactor. Every consultant knows this org. Most have inherited one. The question is what you do in the first weeks: start "fixing" things and hope, or map the ground before you dig.
We call the mapping phase org archaeology, and AI has quietly changed its economics. This is the exact process we ran, with the numbers from our own code audit — the client anonymized, everything else real.
The inherited-org problem
Undocumented orgs are not a hygiene issue. They are a risk multiplier on every change you make afterward. In this org, routing logic was split across record-triggered flows, subflows, Apex, and assignment rules — and because there was no sandbox, every experiment was a production experiment. The people who built the original system were gone. The people mid-refactor were gone too. What remained was behavior: leads got routed, attribution fields got stamped, and nobody could say precisely why.
You cannot safely change a system you cannot describe. The first deliverable of any serious engagement on an inherited org is a description of the org that is actually true.
Step 1: Retrieve everything before changing anything
The first move is mechanical and non-negotiable: pull the entire org into version control. Using the Salesforce CLI, we retrieved roughly 5,200 metadata files — every flow, Apex class, object definition, validation rule, layout, and permission artifact the Metadata API would give us — and committed them to a git repository.
This does three things at once:
- It creates the missing safety net. With no sandbox, the versioned retrieval becomes the rollback reference — a byte-accurate record of what the org looked like before anyone touched it.
- It makes the org searchable. Setup UI navigation is how discovery dies. Grep across 5,200 files answers "what writes to this field?" in seconds.
- It makes the org legible to AI. Language models are very good at reading XML flow definitions and Apex. They cannot click through Setup. A local retrieval turns the whole org into a corpus an AI can actually reason over.
Step 2: AI-assisted synthesis — from 5,200 files to one map
The inventory told us what we were dealing with: 216 flows, 45 custom objects, 51 validation rules, 20 remote site settings, and 13 auth providers — that last pair a quiet warning that this org talked to far more external systems than anyone had mentioned.
Raw metadata is not documentation. The synthesis step is where AI changes the work: with Claude reading the retrieved corpus, we produced a 12-section org overview — data model, automation inventory, routing architecture, attribution logic, integration surface, permission structure, and the defect list — with every claim traceable to a specific file in the retrieval. The consultant's job shifts from reading 216 flows end-to-end to directing the analysis, challenging its conclusions, and verifying the load-bearing ones against the org itself.
Alongside the overview we distilled a condensed "soul doc" — an ORG_MAP file compact enough to load into an AI assistant's context on every future working session. That one artifact compounds: every subsequent question about the org starts from a verified map instead of from zero.
The forensics: what the map surfaced
Synthesis is where an audit earns its keep, because this is where the defects nobody knew about become visible. Three findings from this engagement:
- Two attribution engines writing to the same records. A 729-line Apex attribution class and a newer flow-based engine were both live, both stamping attribution fields, with last-writer-wins behavior depending on execution order. Marketing had been debating numbers that were literally produced by two different systems on different days.
- Two round-robin routing systems coexisting. The mid-refactor state, fossilized: the legacy round-robin and its intended replacement were both active, splitting lead assignment along a boundary no one had documented.
- Live buttons wired to obsolete subflows. Across the ~150 record-triggered flows we analyzed, we found user-facing actions still launching subflows from the abandoned refactor — working just often enough that nobody filed a ticket.
None of these show up in a health-check scanner, and none would have surfaced in stakeholder interviews — because no stakeholder knew. They emerged from reading the metadata as one system, which is precisely the reading that was economically impractical before AI could do the first pass.
Why this beats a traditional discovery phase
Conventional discovery is interview-driven: workshops, process walkthroughs, a slide deck of how the business believes the org works. Belief is useful context, but this engagement is a case study in its limits — the org's actual behavior had diverged from everyone's mental model of it.
Metadata-first discovery inverts the sequence. Retrieve the truth first, synthesize it into a map, then use interviews to explain the anomalies the map surfaces. The output is also a different class of asset: a slide deck decays the day it's presented, while a versioned retrieval plus a maintained org map is queryable infrastructure — diff it after every release and the documentation stays alive.
The honest limits: AI reads what the metadata says, not what the business intends, so it can misjudge which of two duplicate systems is the "right" one — that call needs a human who has asked the revenue team. It can also misread flow semantics on a first pass, which is why every finding that drives a recommendation gets verified against the org directly. And metadata says nothing about data quality or user adoption; those are separate investigations. The AI compresses the reading. The judgment is still the job.
What the client walks away with
- The full metadata retrieval under version control — theirs to keep.
- The 12-section org overview, written for their wiki, plus the condensed org map for AI-assisted work going forward.
- Generated routing diagrams showing how leads actually move — including where the two round-robin systems split traffic.
- A territory-mismatch analysis reconciling assignment behavior against the intended territory model.
- A prioritized risk list: each defect tied to the artifact that causes it and ranked by revenue impact, so the fix sequence is an engineering decision instead of a guess.
Repeatable, not heroic
Nothing here depended on tribal knowledge or a one-off script. The loop is Salesforce CLI for retrieval, git for versioning, and Claude for synthesis — directed and verified by a consultant who has shipped on the platform. If you want to build the same muscle internally, start with our guides on connecting Claude to Salesforce and securing an AI-to-Salesforce connection, or see how we run the pattern day-to-day on our Claude + Salesforce page. And an audit is a beginning, not an end — the org map becomes the operating baseline for ongoing managed work , where every change ships against a description of the org that is known to be true.
Frequently asked questions
What does a Salesforce org audit actually deliver?
A complete metadata retrieval under version control, a structured org overview document, a condensed reference map your team and your AI tools can load, diagrams of the automations that matter most (routing, attribution, integrations), and a prioritized risk list — defects and conflicts ranked by revenue impact, each traceable to the specific flow, class, or rule that causes it.
Is it safe to let AI read our Salesforce org?
The audit works on metadata — flow definitions, Apex source, object schemas, validation rules — not on customer records. Access runs through scoped, authorized credentials, the workflow is read-only, and a senior consultant reviews everything the AI produces before it reaches you. For orgs with regulated data we keep record-level queries aggregate-only.
Do we need a sandbox before an audit can start?
No. The engagement described in this article ran against a production org that had no sandbox at all. Metadata retrieval is a read-only operation, so the audit itself carries no deployment risk — and the versioned retrieval it produces is usually the first step toward finally standing up a real sandbox strategy.
How is this different from an automated org-analysis tool?
Scanners are good at inventory: unused fields, API versions, coverage percentages. They do not tell you that two attribution engines are writing to the same fields, or that a live button launches a subflow that no longer matches the current routing model. That takes cross-artifact reasoning — reading the flow, the Apex it calls, and the page layout that exposes it as one system. That synthesis is what the AI accelerates and a human verifies.
When is an org audit worth doing?
Three moments: when you inherit an org nobody can explain, before a significant rebuild or migration, and before you connect AI tools to Salesforce — an agent grounded in a verified org map gives dramatically better answers than one guessing from raw metadata.
Get the map before you dig
GAT Solutions builds revenue-generating systems for healthcare, accounting, and SaaS companies — fast, flawlessly, and powered by AI. Across 50+ Salesforce projects, the engagements that go wrong are the ones that start changing an org nobody can describe.
If you've inherited an undocumented org — or you're about to make big changes to one — start with our Salesforce org audit. Bring it to a working session and we'll show you what the first retrieval would surface before you commit to anything.