You Just Inherited an Undocumented Salesforce Org. Here's Where to Start.

You Just Inherited an Undocumented Salesforce Org. Here's Where to Start.

You're three days into a new role, or a new client engagement, and you've opened Setup to find exactly what you expected: nothing written down. No handoff notes. No process documentation. A wiki that stopped updating two years ago, if it exists at all. Somewhere in this org are the flows, validation rules, and permission sets that actually run the business, and right now you have no idea which ones matter, which ones are dead weight, and which ones you'll break if you touch them.

This is an extremely common way to start a Salesforce admin job. It's also one of the harder ones, because the standard advice, go slow and understand before you change anything, runs straight into the reality that the business wants changes now and doesn't much care that you just got here.

Why this keeps happening

Documentation gaps aren't a sign of a badly run org. They're what happens to almost every org over time. Most production Salesforce environments are mature: according to Salesforce Ben's 2026 Salesforce Admin Survey, more than 60% are over five years old, and a quarter are more than a decade old. Admins turn over. Consultants finish an engagement and move on. Fields get added for a project that ended eighteen months ago and nobody remembered to clean up. None of that shows up as a single bad decision, it shows up as an org where the person who understands why something was built that way is no longer around to ask.

The same survey backs this up: technical debt is the single most commonly cited challenge admins report. It compounds in older, more customized orgs, exactly the ones most likely to land on a new admin's desk with no notes attached.

Resist the urge to start changing things

The instinct on day one is to fix the thing that's obviously broken. Don't, yet. An undocumented org is full of dependencies you can't see from the surface: a validation rule that looks redundant might be the only thing preventing a data quality issue nobody's had in years because that rule has been quietly doing its job. Spend the first stretch understanding the org as it exists, not as you'd have built it.

What to actually check first

A reasonable first pass covers four things, roughly in this order:

  • Users and licenses. Who's active, who isn't, what profiles and permission sets are actually assigned versus what's just sitting unused.
  • The automation layer. What flows are active, what triggers them, and what they touch. This is usually where the real business logic lives, and where the biggest risk sits if you change something blind.
  • Security and sharing. Profiles, permission sets, field-level security, and sharing rules, so you understand who can see and change what before you're the one answering for it.
  • Data quality basics. Duplicate risk, stale records, and whether the fields people rely on are actually being filled in consistently.

Doing this manually means clicking through Setup, exporting metadata by hand, and building your own spreadsheet of what you find, if you have the time for it. Most people inheriting an org don't.

Where this goes faster with an AI admin tool

This is exactly the kind of work that natural-language access to your org's metadata speeds up, because the bottleneck isn't judgment, it's the sheer number of screens you'd otherwise have to click through to build a picture of what's there.

Connected through Claude, ChatGPT, Cursor, or any MCP-compatible AI tool, Cirra AI lets you ask directly: which flows are active on the Opportunity object, what validation rules exist on Accounts and what do they check, which permission sets grant edit access to a given field. You get answers in plain language, sourced from the org itself, not from documentation that may not exist or may be wrong.

For a fuller pass, Cirra AI's org audit skill works through the metadata systematically, checking flows, permission sets, and the rest of what's live, and surfaces what's worth prioritizing first. Turn what it finds into a written summary you hand up to a manager or keep as the documentation the org never had. That summary becomes your baseline: the thing you compare against six months from now to see what's actually changed.

Turn what you learn into documentation that outlives you

The point of this exercise isn't just to get yourself oriented. It's to leave the org better documented than you found it, so the next person, or you, eighteen months from now, isn't doing this same exercise from scratch. Once you've mapped the automation and permission structure, use that same natural-language access to generate documentation as you go: ask for a plain-English summary of what a flow does before you edit it, and keep that summary somewhere your team will actually find it.

If you want a deeper walkthrough of running a full metadata audit, see our companion piece, How to Audit Your Salesforce Org's Metadata Without a Developer, which covers the audit process in more depth once you're past this initial orientation stage.

Start where you are

Inheriting an undocumented org isn't a problem you solve on day one, and it isn't a reason to freeze. Get oriented on the pieces most likely to break something if you touch them blind, use AI to compress the discovery work from weeks to hours, and start writing down what you learn as you go. The org will still be complicated. It just won't be a mystery.

Ready to see what's actually in your org?

Connect your Salesforce org and start a free trial to ask Cirra AI directly, or book a demo to see the org audit workflow walked through on a real org.

Share the Post:

Related Posts