A distributor came to us with a Salesforce org that technically worked and practically did not. They had gone live, trained their team, and then watched everyone quietly drift back to spreadsheets within a few months. The sales reps did not trust the data, the commercial team could see numbers they should never have seen, and nobody could say with confidence what the previous partner had actually built. Before we promised them a rebuild, we ran a full salesforce org assessment, because the reasons an org fails the first time are almost always still wired into it, and you cannot fix what you have not measured. This is the assessment we run on every inherited org, walked through in the order we run it.
We lean on two Salesforce frameworks as our lenses throughout. Well-Architected gives us the three pillars (Trusted, Easy, Adaptable) to organize what "good" means, and the Security Health Check gives us a scored, defensible baseline for the security pillar so that when a client asks "compared to what," we have an answer.
Start With the Org Baseline and Licenses
Before judging anything, you need to know the shape of the org. We record the edition, the license counts, and the storage and API headroom, because those numbers tell you both the operational scale and what the previous team was provisioned to do. This org was Enterprise Edition using 61 of 83 platform licenses, with 22 spare. More interesting were the licenses nobody mentioned: a large block of Einstein Agent licenses already sitting there, a Partner Community allocation provisioned but completely unused, and several integration user licenses in play. Storage and API limits had enormous headroom, so performance pressure was never the problem here.
This step rarely uncovers the headline issue, but it frames everything after it. Knowing the org was already paid up for AI and partner portal capability, for example, changes the rebuild conversation from "what can we afford" to "what are you already entitled to use."
Security and Access Is Where Inherited Orgs Hurt Most
This is the section that usually explains why a go live failed, and it did here. The Health Check score was 61 out of 100, which is low enough to be a finding on its own. Multi-Factor Authentication was switched off entirely, which is a Salesforce requirement and a non-negotiable fix. System Administrators made up 19 percent of users, against a recommended baseline of about 5 percent, meaning roughly one in five people could change anything in the org. The password policy was weak, admins could log in as any user without a forced re-login, and clickjack protection was off.
The most damaging finding was the sharing model. Org-Wide Defaults were set to Public Read Write internally on Account, Quotation, and Sales Order. In plain terms, every user could see and edit everyone else's records, including the cost and margin fields that should never leave the commercial team. This client needed isolation by business unit and by country, and the org was doing the exact opposite. The correct model is Private at the org-wide default, opened up deliberately through sharing rules, with field-level security hiding sensitive fields from anyone who does not need them. That gap, more than any single bug, was why people stopped trusting the system.
Data Model and Data Quality
Here we map what was built and how clean it is. The previous partner had built quoting on custom objects rather than standard Quote and Order, with a chain of Quotation, Quote Line Item, Sales Order, and a subsidiary junction linking customers to subsidiaries at both the customer level and the per-transaction level. Custom objects are not wrong by default, but they are a commitment, so we flag every one and ask the client which they genuinely depend on operationally and which exist only because someone built them. The transactional tables had been reset to empty, so true data quality could not be scored yet, but the catalog held over 6,000 products and roughly 94,000 price book entries, which told us the product and pricing foundation was real and worth preserving.
Automation Inventory
Automation health is not about how many automations exist, it is about how they stack. The good news here was that the org carried zero Workflow Rules and zero Process Builders, so there was no legacy automation to migrate. Most logic lived in Flow plus eight Apex triggers, which is a modern footprint. The concern was concentration: one object fired 12 record-triggered flows on save, with others firing six and five. Multiple record-triggered flows on a single object is exactly where order-of-execution and performance problems hide, because Salesforce does not guarantee the order they run in. We flag these for consolidation before they become the next round of mysterious bugs.
Code Quality and Test Coverage
Inherited code is not free just because it is already written. This org had 243 Apex classes built on the fflib enterprise patterns framework, which is genuinely good news, because well-structured code is far easier to take on than a tangle of ad-hoc triggers. The numbers underneath were the problem. Org-wide test coverage was 74 percent, which sits just below the 75 percent Salesforce requires to deploy, and running the full suite produced a meaningful share of failures. Worse, the two classes that actually move data in and out of the ERP sat near 7 percent coverage, meaning the integration was effectively untested. We wrote separately about what inherited code coverage really tells you, because a single coverage percentage hides exactly this kind of dangerous distribution. The practical consequence: this code could not be deployed as-is, and the test suite needed real work before any of it could be reused. For the longer view on cataloguing this kind of liability, see the technical debt field guide.
Integration Review
The org synced with a NetSuite ERP through Apex, authenticating with OAuth, and it carried a few patterns we always check for. First, the credentials were stored in Custom Labels rather than a Named Credential, which is both a security smell and an operational chore, since Custom Labels are visible in Setup and have to be edited by hand per environment. We treat that as a standard fix and explained why in secrets in Custom Labels. Second, the External Id strategy was inconsistent: products carried the NetSuite Id, but accounts stored the relationship the other way around, which makes reliable upsert on re-sync fragile and invites duplicates. Standardizing every synced object to carry the external system's Id is the kind of unglamorous fix that prevents months of reconciliation pain.
The Ownership Bug We Found
Every assessment turns up one quiet defect that explains a disproportionate amount of the client's pain, and here it was record ownership. Account owners were set to the integration user rather than the sales rep who actually managed the account. The cause was simple: the sync code created accounts without setting an OwnerId, and Salesforce assigns ownership to the running user when none is specified. Because the sync ran as the integration user, every synced account fell to that one account. Reps could not find their own customers, reports rolled up to the wrong people, and the whole thing reinforced the sense that the data was not theirs. We documented the full mechanism in the integration user ownership bug, because it is one of the most common and most underestimated defects in inherited orgs.
Takeaway
An inherited Salesforce org rarely fails for one dramatic reason. It fails because a sharing model exposed data people should not see, because admin rights were handed out too freely, because the automation stacked up quietly, and because a small sync defect put every record under the wrong owner. None of that is visible from the outside, and none of it gets fixed by rebuilding on top of the same assumptions. A proper salesforce org assessment, measured against Well-Architected and the Security Health Check rather than gut feel, is what separates a rebuild that sticks from another failed go live. If you have an org that technically works but nobody trusts, reach out and let us run this assessment before you spend another budget cycle building on top of it. You can see how we approach the rebuild that follows on our services page.
