Every Salesforce org older than five years has the same conversation eventually. Someone asks why a simple change, adding one picklist value, say, takes three days and touches four different automations. The answer is never one thing. It’s a decade of reasonable decisions that stopped being reasonable once they piled up.
I’ve walked into more than one org where the object model told the story of the company’s history better than any wiki did. A field called Legacy_Region__c that nobody uses anymore but three validation rules still reference. A Process Builder flow built in 2019, replaced by a Flow in 2022, except the old one was never deactivated because someone was worried something depended on it. Nobody remembers what, so it stays.
Technical debt in Salesforce doesn’t look like technical debt
In a codebase, debt is usually visible: duplicated functions, missing tests, a file nobody wants to open. In Salesforce, it hides inside declarative tools that were designed to feel safe and reversible. That’s the trap. Flows, validation rules, page layouts and permission sets all feel low-risk to add. Almost nothing about the platform makes it feel expensive to leave them there once they’re outdated.
So the debt accumulates quietly. A workflow rule from 2018 firing alongside a Flow built in 2023 doing something similar. Sharing rules layered on top of role hierarchy changes that never got cleaned up. A dozen record types on Opportunity, half of which one team uses and the other half inherited from a merger nobody talks about anymore.
None of this shows up as an error. The org runs. Reports still generate. That’s exactly why it survives for years: there’s no exception in the debug log for “this design decision made sense in 2016 and now costs you two hours per release.”
Where it actually accumulates
A few places I check first on any long-lived org, roughly in the order the cost tends to show up:
- Automation sprawl. Workflow rules, Process Builder, and Flow, often all three, doing overlapping things on the same object. Each one was the “right” tool when it was built. Nobody goes back and consolidates once the platform moves on.
- Field bloat. Custom fields that were needed for a project that ended two years ago. Every extra field is a line item in every future data migration, every integration mapping, every user training session.
- Permission model drift. Profiles built for a team structure that got reorganised twice since. Permission sets added on top instead of profiles being revisited, because touching a profile feels riskier than it is.
- Integration middleware nobody owns. A point-to-point callout built for a system that’s since been replaced, still running, still consuming API calls, because decommissioning it means finding out what else might be quietly relying on it.
The metric that actually shows the cost
Forget “technical debt” as a vague feeling for a second. The number that tends to convince a skeptical stakeholder is release lead time: how long it takes from “we’ve agreed on the requirement” to “it’s live in production.” On a clean org, a small enhancement should move in days. On a decade-old org with unmanaged debt, I’ve seen that same class of change take three or four weeks, not because the work is hard, but because nobody’s confident what else it’ll touch.
That’s the real cost. Not that the platform breaks. It’s that every change gets slower and every estimate gets padded, because the safe move is always “test everything” instead of “test the thing we changed.”
Deciding what to fix and what to leave alone
You can’t clean up a decade of decisions in one project, and trying to is how technical debt initiatives die. I generally sort candidates into three groups.
Fix now
Anything actively causing incidents or blocking current work. If a validation rule is throwing false positives for a live business process, or two automations are creating duplicate records, that’s not debt anymore, that’s a bug wearing debt’s clothes. Fix it regardless of whether there’s a broader cleanup initiative funded.
Fix opportunistically
Anything sitting directly in the path of a planned enhancement. If you’re already touching the Case object for a new requirement, that’s the moment to retire the two dead workflow rules on the same object, not six months later in a separate project that will never get prioritised on its own.
Leave alone, but document
Old automation that isn’t causing harm and isn’t in anyone’s way. The instinct to “clean everything” is expensive and rarely worth it. What matters more is that someone writes down what it is and why it exists, so the next person doesn’t spend half a day reverse-engineering intent from Apex comments that were never written.
Making the business case
The mistake I see most often is technical teams asking for “time to pay down technical debt” as a standalone ask. That request loses against a feature roadmap every time, because it has no measurable outcome attached to it.
What works better: tie the cleanup to the thing leadership already cares about. If release lead time is the pain point, propose reducing it from three weeks to one, and name the automation consolidation work required to get there. If it’s onboarding time for new admins, tie the field and record-type cleanup to a specific reduction in ramp-up time. A composite example I’ve used before: an org with 40+ unused fields on Contact, cleaned down to the dozen actually referenced anywhere, cut the time for a new admin to confidently make a change from a couple of weeks to a few days, mostly because they stopped second-guessing what was safe to touch.
What good looks like a year later
You’ll know the debt work is paying off when small changes stop needing a war room. When someone can look at the automation on an object and understand, within ten minutes, what runs and why. When the person doing a release doesn’t need to test the whole org because they trust the boundaries of what they changed.
That’s not a glamorous outcome to put in a project readout. It also happens to be the one that determines whether every future project on that org moves at a reasonable pace or grinds along at the mercy of a decade of decisions nobody’s revisited.