The Org Autopsy: What I Check First When Companies Hire Me to Fix Their Salesforce
Part 1 of 10 in the series: What Your Salesforce Org Says About Your Company
The first thing I do when a company hires me to fix their Salesforce org is run an autopsy.
Not because the org is dead. Nobody can tell me what's alive.
Last year, a mid-size nonprofit brought me in after their third admin quit in 18 months. The VP of Operations opened the call with: "We need someone to just make it work again." I asked five questions in the first 30 minutes.
How many active automations do you have? "I'm not sure."
Who built them? "Different people over the years."
When was the last time someone audited your custom objects? Silence.
Is there documentation? "There might be something in a Google Doc somewhere."
Who is your data steward? "What's a data steward?"
Five questions. Five non-answers. That told me more about the org's health than any dashboard could.
I quoted $8,500 for a two-week assessment. They hesitated. Six weeks later they called back because an automation was sending duplicate donation receipts to major donors. The emergency fix cost $4,200. The assessment would have caught it on day three.
Why Org Health Degrades
Nobody builds a bad org on purpose. Org health degrades through accumulation, not intention. Here's how it happens.
The Revolving Admin Door. Most Salesforce orgs have had 3-5 different administrators over their lifetime. Each admin inherits the previous admin's work, doesn't fully understand it, builds on top of it, and leaves. The next admin inherits two layers of undocumented work. By the third admin, the org is a geological formation: layers of logic stacked on top of each other with no map.
The "Just Make It Work" Culture. Stakeholders don't ask for architecturally sound solutions. They ask for the thing they need by Thursday. The admin builds it fast, ships it, and moves to the next request. Documentation happens "later." Later never arrives. The fast fix becomes permanent infrastructure.
No Dedicated Architect. Most orgs under 500 users don't have a Salesforce architect. The admin handles configuration, user support, reporting, data quality, and strategic planning. That's five jobs. Architecture is the first one that gets deprioritized because it doesn't have a deadline attached to it.
The Upgrade Treadmill. Salesforce releases three major updates per year. Features change. Best practices shift. Workflow Rules became Process Builders became Flows. If nobody is proactively reviewing the org against current standards, legacy configurations accumulate. I still find active Workflow Rules in production orgs in 2026. They work. They're also deprecated, unsupported, and impossible to troubleshoot alongside modern Flows.
The Fear of Breaking Things. Once an org reaches a certain complexity, people stop changing things. "Don't touch it, it works" becomes the unwritten policy. Dead automations stay active. Unused objects stay in the schema. Redundant fields stay on page layouts. The org grows in every direction and never shrinks. That's how you end up with 400 custom objects and 200 Flows without anyone noticing the number climbed that high.
How to Run Your Own Org Autopsy
You don't need to hire a consultant to run a basic health check. The five checkpoints below take 2-3 hours and will tell you more about your org than any executive dashboard.
Checkpoint 1: Automation Inventory
Navigate to: Setup → Process Automation → Flows
Count everything. Active Flows, inactive Flows, Flows starting with "Copy of," Flows with no description. Then check for legacy automations that should have been migrated years ago.
Navigate to: Setup → Process Automation → Process Builder
If you find active Process Builders, flag them. Salesforce stopped supporting Process Builder in favor of Flows. Any active Process Builder is technical debt waiting to cause a problem.
Navigate to: Setup → Workflow Rules
Same assessment. Active Workflow Rules should be migrated to Flows. If they're still running, nobody has updated the automation layer in at least two years.
What to record:
Total active Flows, Flows with no description, Flows starting with "Copy of," active Process Builders (should be zero), and active Workflow Rules (should be zero).
What the numbers mean:
Fewer than 20 active Flows with descriptions means a healthy automation layer. Between 20-50 Flows with mixed documentation means moderate debt; schedule a Flow audit within 60 days. More than 50 Flows, many undocumented, means significant debt. You need a Flow consolidation project before building anything new.
Checkpoint 2: Object Model Audit
Navigate to: Setup → Object Manager
Sort by custom objects. Count the total. Then check the record count on each by opening the object and viewing a list view, or by running a quick report.
Categorize every custom object into three buckets:
Active: has records AND has automations or is referenced in reports. This object is doing work.
Dormant: has records but no automations, no reports, no page layouts referencing it. This object was useful at some point and may still hold historical data.
Ghost: has zero records. Nobody has ever created a single record in this object. It exists because someone asked for it, someone built it, and nobody went back to check whether it was used.
The Ghost Object Ratio is your technical debt score. Divide ghost objects by total custom objects. If more than 30% of your custom objects have zero records, your data model was built reactively, not architecturally.
At the nonprofit I mentioned earlier, the Ghost Object Ratio was 78%. Out of 400 custom objects, 312 had zero records. Someone had built them for a stakeholder request, the request changed or was abandoned, and nobody ever went back to delete the object. Each one added complexity to the schema, confusion to the Object Manager, and noise to every conversation about "what does our data model look like."
Checkpoint 3: Data Quality Baseline
This checkpoint requires SOQL queries or reports. Run these against your production org.
Accounts with no owner:
Open Developer Console (Setup → Developer Console) or use Workbench. Run:
SELECT COUNT() FROM Account WHERE OwnerId = null
Opportunities with no close date:
SELECT COUNT() FROM Opportunity WHERE CloseDate = null
Contacts with no email:
SELECT COUNT() FROM Contact WHERE Email = null
Calculate percentages against your total record counts. Here are the benchmarks I use:
Accounts with no owner: should be below 5%. Opportunities with no close date: should be below 3%. Contacts with no email: should be below 10%.
If any of these numbers are above 20%, your reports are unreliable. Every dashboard built on this data is telling a partial story. This is how "I'll just use Excel" culture starts. One executive sees a number that doesn't match their spreadsheet, loses trust in the platform, and tells their team to stop using Salesforce for reporting. Six months later, nobody looks at dashboards. A year later, someone asks why they're paying for Salesforce at all.
Checkpoint 4: Sharing Model Review
Navigate to: Setup → Security → Sharing Settings
Check your Organization-Wide Defaults (OWD) for every standard and custom object. The default out of the box is "Public Read/Write," which means every user can see and edit every record on that object.
For an org with fewer than 20 users in one department, this is acceptable. For an org with 50+ users across multiple teams, regions, or business units, this is a governance failure. Sales reps can see HR cases. Marketing can edit finance records. Not because someone designed it that way. Nobody changed the default.
Check these objects specifically:
Account OWD: should be Private or Public Read Only for multi-team orgs. Contact OWD: should be Controlled by Parent or Private. Opportunity OWD: should be Private for any org with a sales team. Case OWD: should be Private for any org handling sensitive customer or HR cases.
Navigate to: Setup → Security → Sharing Rules
Count your sharing rules. If you have zero sharing rules and your OWDs are all Public Read/Write, nobody designed your sharing model. It was left at default. That's the equivalent of building a house and never installing locks on the doors.
Checkpoint 5: Integration Documentation
This checkpoint doesn't have a Setup path because integration documentation lives outside of Salesforce, if it lives anywhere at all.
For each integration in your org, answer six questions: What systems does it connect? What data does it move, and in which direction? What credentials does it use? When was the last time someone tested it? What happens when it fails? Who is responsible for maintaining it?
If you can answer all six for every integration, your integration layer is documented. If you can't answer even one question for any integration, you have an undocumented dependency running in production. That integration is surviving on institutional memory. Institutional memory leaves the company when the person who built it leaves.
How to Prevent Org Health Degradation
Assessment without governance is a one-time exercise. The org will degrade again within 12 months if you don't put ongoing rules in place.
Quarterly Automation Audit. Every 90 days, run Checkpoint 1. Deactivate anything unused. Document anything undocumented. Consolidate redundant Flows. This takes 2-3 hours per quarter and prevents the automation layer from becoming unmanageable.
Annual Object Model Review. Once per year, run Checkpoint 2. Delete ghost objects after confirming they're truly unused. Archive dormant objects. Keep the data model intentional.
Monthly Data Quality Check. Run the SOQL queries from Checkpoint 3 monthly. Track the percentages over time. If data quality is improving, your validation rules and user training are working. If it's declining, something is broken in your data entry process or your validation rules have gaps.
Sharing Model Review at Every Major Org Change. Any time you add a new department, a new business unit, or a new user population, revisit Checkpoint 4. The sharing model should match the current organizational structure, not the one from three years ago.
Integration Documentation as a Deliverable. Every new integration must include a one-page documentation template as a project deliverable. Not optional. Not "we'll document it after go-live." The documentation ships with the integration or the integration doesn't ship.
Download the Org Health Checklist
The companion checklist includes all five checkpoints in a printable format with scoring. Run it against your org this week. It takes 2-3 hours. The results will tell you whether you have a healthy org, moderate technical debt, or a foundation that needs stabilization before you build anything new on top of it.
I've used this same checklist on every assessment engagement for the past three years. The $8,500 assessment I quoted that nonprofit? It started with this exact document. The checklist is the first page of every engagement. Now it's yours.
Download the Org Health Checklist below. It's free.
Part 1 of 10 in the series: What Your Salesforce Org Says About Your Company.