You get dropped into a new org with no handover doc, maybe a Slack message that says “here’s access, good luck.” This happens constantly in consulting and platform support work: a client project starts, the previous partner is gone, and you’re the one who has to figure out what you’re actually dealing with before you write a single line of code. I’ve done this often enough now, across Service Cloud, Marketing Cloud and straight enterprise Apex orgs, that I’ve got a fixed order I run through. Not because the order is sacred, but because skipping steps is how you end up three weeks in, discovering the sharing model is held together with a single “grant access using hierarchies” checkbox and a prayer.
Start with who can see what, not what the org does
The instinct is to go look at the automation first, because that’s where the interesting bugs usually are. Resist it for ten minutes. Security model first, every time.
I check org-wide defaults before anything else. Private, Public Read Only, Public Read/Write on the big objects (Account, Contact, Case, whatever custom objects carry the real business process). That one setting tells you more about how the org actually works than a week of reading Apex. An org with everything set to Public Read/Write usually means sharing rules were never designed properly, just avoided. An org with everything Private and forty sharing rules layered on top means someone tried to do it right and the business kept adding exceptions.
Then profiles and permission sets
Count them. A client org running a few hundred users with sixty profiles is telling you something: profile sprawl almost always means permissions got bolted onto profiles instead of layered through permission sets, which means every new requirement turns into a new profile clone instead of a clean add. I pull the profile-to-user-count breakdown early. If half the profiles have one or two users assigned, that’s legacy cruft nobody cleaned up.
Automation habits tell you about the team, not just the org
Once I’ve got the security shape, I move to automation. Not to read every flow line by line, that comes later. I’m counting and categorising.
- How many triggers exist per object, and is there one trigger per object or five fighting each other?
- Are flows and Apex triggers doing the same job on the same object, silently racing?
- Is there a trigger framework, or did everyone just add an “if” block to the last trigger that existed?
- Field update automation: are there process builders still live alongside newer flows, both firing?
This is where you find the actual risk. I’ve walked into orgs where a single Account update triggered four separate automations that each queried the same related list, none of them aware the others existed. Nobody intended that. It accreted, release by release, because nobody was checking what already ran before adding something new. Thirty minutes won’t tell you every interaction, but it tells you whether bulk safety was ever a design principle or an afterthought.
A quick governor-limit sanity check
I’ll run a rough check on the heaviest objects: largest data volume, most automation attached, most integration traffic. If those objects also have SOQL inside loops or non-bulkified DML, that’s not a future problem, that’s a live one waiting for the next data load or integration batch to hit a limit. Worth flagging immediately, before you’re blamed for a failure that predates you.
What’s actually bolted onto the data model
Next, the object model itself. Standard objects customised past recognition are common and not inherently bad, but I look for the tells of a model that grew without anyone stepping back: custom fields with names like Temp_Field_2__c still in active use, lookup relationships where a master-detail should exist (or the reverse), and record types that have multiplied because someone needed “basically the same thing but slightly different” and nobody wanted to refactor.
I also check whether Marketing Cloud and Service Cloud (when both exist) actually agree on where contact data lives, or whether there are two versions of the truth syncing in one direction only. That mismatch is one of the most common sources of “why does this contact look different depending on which system you’re in” tickets, and it’s rarely obvious from the data model diagram alone, if one even exists.
Integration points: where the org actually talks to the outside world
Every org has integration points, and most of the ones that cause outages weren’t designed, they accumulated. I look for Named Credentials and External Credentials first, because that tells you what’s connected and how recently someone bothered to use the newer, more secure pattern versus a legacy hardcoded endpoint sitting in a custom setting from 2019. Then API usage: is the org anywhere near its daily limit, and if so, is that from one chatty integration or genuinely high real-time volume? Those two situations need completely different fixes.
Release process, because it tells you what breaks next
Last thing in the thirty minutes, and arguably the most predictive: how does code actually get to production here? Is there a CI pipeline with real test gates, or is someone doing manual change sets at 6pm on a Thursday? I’m not judging the team for whatever I find, every org has a history and most of these patterns exist for a reason that made sense at the time. But the release process tells you how fragile the next six months will be, and whether the technical debt you’re seeing in the data model and automation is actively getting worse or is at least being managed.
Why this order, specifically
Security first because it’s the hardest thing to retrofit safely once business processes depend on the current (possibly wrong) access model. Automation second because that’s where live risk sits. Data model third because it’s slower-moving and more forgiving of a short delay in understanding it properly. Integrations and release process last in this pass, not because they matter less, but because by that point you’ve got enough context to actually interpret what you’re looking at instead of reading it cold.
None of this replaces a proper discovery phase. Thirty minutes won’t surface everything, and it shouldn’t try to. What it gives you is an informed starting point: the three or four things worth asking the client or the previous team about before you commit to an approach, and the confidence that whatever you build next won’t quietly collide with something that was already there.