What you are trying to establish
Three things: can we safely change this, what will break first, and what did previous work leave behind? Not a complete inventory of imperfections — a prioritised list of what actually threatens you.
Inheriting a Salesforce org — after an acquisition, a consultant change, or an admin departure — starts with knowing what you are holding.
The seven areas to assess
| Area | What to check | Red flag |
|---|---|---|
| Automation inventory | Every trigger, Flow, process per object | Multiple competing on one object |
| Bulk safety | Behaviour on 200-record operations | Failures on data import |
| Test coverage | Quality, not just percentage | Tests that assert nothing |
| Security model | Profiles, permission sets, sharing | Widespread "Modify All" |
| Integrations | Error handling and reconciliation | Silent failure on outage |
| Data quality | Duplicates, orphans, required fields | Reports nobody trusts |
| Technical debt | Unused fields, dead code, old packages | Nobody knows what is still needed |
Test coverage percentage is the most misleading metric in Salesforce. Salesforce requires 75% to deploy, so every org has it. What matters is whether the tests assert anything meaningful and whether they exercise bulk conditions. Tests that insert one record and check nothing satisfy the requirement and prove nothing.
Week one: what exists and what fails
- Inventory automation per object. Every trigger, Flow, process builder and validation rule. This list alone frequently surprises people.
- Run a bulk test in a sandbox — insert and update two hundred records on your key objects. Record what fails.
- Read the test classes. Do they assert outcomes, or just execute code? Do any create bulk data?
- Check the security model — how many profiles have broad permissions, and does anything need them?
- Test integration failure behaviour — what happens when the external system is unavailable?
- Review recent deployment history — frequent hotfixes indicate fragility.
The findings that matter most
| Priority | Finding | Why urgent |
|---|---|---|
| Immediate | Data exposure through sharing gaps | Confidentiality risk today |
| Immediate | Integrations failing silently | Data diverging unnoticed |
| Urgent | Bulk failures on core objects | Blocks data operations |
| Urgent | No meaningful test coverage | Every change is a risk |
| Important | Competing automation on one object | Unpredictable behaviour |
| Planned | Unused fields and dead code | Maintenance drag |
Sharing model problems come first because they are the only category where the damage is happening right now rather than waiting for a trigger.
The sharing model deserves particular attention
It is the most commonly misconfigured area in inherited orgs, and the consequences are the least visible:
- "View All" and "Modify All" granted broadly to solve a permissions problem quickly.
- Apex running "without sharing" where it does not need to, bypassing record access.
- Field-level security not enforced in custom code or components.
- Public read-write org-wide defaults set during implementation and never tightened.
- Sharing rules layered until nobody can determine who sees what.
A quick check that finds real problems: log in as a standard user from a different team and try to view records they should not see. Permission architecture diagrams frequently do not match actual behaviour, and this test takes ten minutes.
What the audit should produce
- Can we deploy a change safely today? Yes or no, with specifics.
- A prioritised finding list, with the top three named.
- An estimate for stabilising the immediate and urgent items only.
- A recommendation on automation consolidation.
- What remains unknown and what it would take to find out.
Stabilising before building
- Fix security exposure — sharing gaps and over-broad permissions first.
- Add error surfacing to integrations so failures stop being silent.
- Remediate bulk failures on core objects.
- Add meaningful tests around the paths you intend to change.
- Consolidate competing automation per object.
- Then build new functionality, on a foundation you can trust.
That order matters. Building on an org you cannot deploy to safely compounds the problem rather than adding value.
Inherited an org nobody wants to touch? Tell us what you know about it — we audit before quoting any build work. See our Salesforce service, governor limits, and general codebase audits.