8 Signs Your Salesforce Org Is a Mess (And How to Fix It)

A messy Salesforce org is one of the most common, and most expensive, problems we inherit. It rarely happens through one bad decision. It accumulates: a field added here, a flow bolted on there, a workflow nobody remembers building, year after year, until reports are unreliable, automation fights itself, and reps have stopped trusting the data.

The good news: a messy org almost never needs a full re-implementation. It needs a structured cleanup. Here are the eight signs your org has drifted, and the playbook to fix each.

1. Field sprawl

The sign: hundreds of custom fields, most with single-digit fill rates. The page layouts are walls of fields nobody fills in.

Why it happens: every request ("can we track X?") became a new field, and nobody ever removed one.

The fix: get fill rates first. Salesforce Optimizer, in Setup, reports unused fields and unused reports for free, and Field Trip does the same with better per-field detail. Anything under about 5% fill is a candidate for deletion or consolidation.

Candidate, not corpse. Fill rate alone will get you into trouble, because a field nobody populates can still be referenced by a Flow formula, an integration user's API call, or a report that only runs at quarter close. Open Where is this used? on each field before you touch it; that view is the difference between a cleanup and an outage.

Two Salesforce specifics worth knowing before you start deleting. A deleted custom field sits in Deleted Fields for 15 days and is recoverable, which is your safety net, and it still counts against the per-object field cap until it's erased, which is why "we deleted 200 fields" sometimes doesn't free up room to add one. And do it in a sandbox, then watch a full close cycle before repeating it in production.

2. Conflicting automation

The sign: you change a record and something unexpected happens: a field gets overwritten, a status flips back, a record reassigns itself. Debugging takes hours.

Why it happens: multiple flows (and leftover Workflow Rules / Process Builder) all fire on the same record event and fight over the same fields.

The fix: one owner per field. Decide which automation owns each field, and stop the others writing to it.

The ordering is what makes this debuggable, and it is not intuitive. Before-save flows run before validation rules, so a before-save flow can write a value that then fails validation and rolls the whole transaction back, which surfaces to the user as a validation error on a field they never touched. After-save flows run later and can retrigger the same record, which is how you get a status that flips back a second after someone sets it. If you have both firing on one object, the after-save one is usually where the fight is. The Flow versus Apex piece has the full order.

The other thing we reach for here is Setup Audit Trail. It only keeps about six months in the UI, but six months is usually enough to find out who added the flow nobody remembers and what else they changed that week.

3. Dead and duplicate workflows

The sign: dozens of active flows, and nobody can tell you what half of them do or whether they're still needed.

Why it happens: automation got built by people who've since left, for processes that have since changed.

The fix: inventory every active automation with its trigger and its purpose, then triage: keep, consolidate, or kill.

In the orgs we inherit, a meaningful share of active automation turns out to be doing nothing at all, and the two reasons are worth checking for directly. Either its entry criteria can no longer be met, usually because a picklist value it tests for was renamed and the flow still tests the old string, or a later flow overwrites its work inside the same transaction, so it runs successfully and changes nothing that survives. The first shows up as a flow with zero interviews in the last quarter. The second only shows up if you read both flows.

Deactivate rather than delete, leave it off for a full billing cycle, and only then remove it. Deactivating is instant and reversible; deleting a flow with a live interview is neither.

4. Data you don't trust

The sign: two reports give two different revenue numbers. Reps keep a private spreadsheet because they don't believe the CRM. Leadership asks "which number is right?" in every meeting.

Why it happens: duplicates, missing required fields, and inconsistent formats accumulated faster than anyone cleaned them.

The fix: the full data quality playbook: deduplicate, normalize, enrich, then build the ongoing hygiene automation so it stays clean. Without that maintenance layer the mess rebuilds in 6 to 12 months, because the thing that created it is still running.

One warning about the cleanse itself, which we have learned the hard way. Merging duplicates rewrites record IDs, and anything holding the losing ID breaks quietly: report filters pinned to a specific account, campaign member lists, integration mappings in n8n or Zapier that cache an ID rather than looking it up, and Chatter follows. Export the merge map before you run it, because "which record did this become?" is a question you will be asked a week later.

5. Report and dashboard chaos

The sign: hundreds of reports, no naming convention, and nobody knows which dashboard is the "real" one.

Why it happens: everyone built their own reports, none got cleaned up.

The fix: designate a small set of canonical dashboards (5–8), document the metric definitions behind them, and archive the rest. Inconsistent definitions ("what counts as pipeline?") cause more confusion than missing reports.

6. Validation rules that block legitimate work

The sign: reps complain they can't save records, or worse, they've found workarounds that defeat the rule entirely (putting junk in required fields just to move on).

Why it happens: validation rules got added reactively without considering the real workflow.

The fix: audit validation rules against how people actually work. A rule that gets worked around is worse than no rule: it produces fake data. Keep the rules that protect data integrity; cut the ones that just create friction.

7. Permission and security drift

The sign: nobody's sure who can see or edit what. Former employees still own records. New hires get access by cloning whoever sits near them.

Why it happens: profiles and permission sets accumulated exceptions over years.

The fix: audit profiles and permission sets, reassign records owned by inactive users (automate this going forward), and rebuild access around roles rather than individuals.

8. Hardcoded references that break

The sign: automation assigns leads to people who left months ago, or matches on company names that have since changed.

Why it happens: user IDs, names, and channel IDs were hardcoded inside flows.

The fix: move references to external configuration (a custom object or setting), reference users by role rather than name, and add a quarterly review for anything that must stay hardcoded. See the common automation bugs post for the full pattern.

The cleanup playbook

The order matters: cleaning in the wrong sequence creates more mess:

1. Audit first. Field usage, automation inventory, data quality, permissions. Measure before you touch anything.
2. Deduplicate data. Other cleanup creates more duplicates if you don't do this first.
3. Kill dead automation and fields. Remove what nobody uses.
4. Resolve conflicts. One source of truth per field.
5. Normalize and enrich data. Then build the hygiene automation that keeps it clean.
6. Rebuild reporting. Canonical dashboards with documented definitions.
7. Document everything. So the next person doesn't recreate the mess.

A typical org cleanup runs 3–6 weeks: a fraction of a re-implementation, with most of the benefit.

Count how many of the eight you recognized

One or two? You have a ticket, not a project. Fix them on a Friday and get on with your quarter.

Five or more, and the org isn't really the problem. The org is a record of a change process that lets anyone add a field, bolt on a flow, or write a validation rule without a second person looking at it. Clean it up and the symptoms go away for a while. Then the same requests arrive, get answered the same way, and you're back here in a year wondering why. That's the part cleanup projects skip, and it's why some orgs get cleaned twice.

Which makes the first question something other than "what do we delete." It's: who approves the next new field, and where is that written down? If nobody in your org can answer that today, start there. The deletion list is the easy half. And a cleanup with governance attached is still cheaper and far less disruptive than moving platforms, which costs you your history on top of everything else.

Nobody who built the org can audit it honestly, which is the whole reason outside eyes are worth paying for here. Three to six weeks, depending on how much of it there is.