SympleOps
Salesforce Technical Debt
Technical debt in Salesforce is rarely one bad decision. It is a hundred reasonable ones, each made by someone who understood the context at the time and had no reason to write it down. This page covers where it accumulates, how to see it before it bites, and how to pay it down without freezing delivery.
The reason Salesforce technical debt is awkward to talk about is that none of it looks like debt while it is being created. Every individual change shipped fine. The cost only shows up later, as slower delivery and more defensive answers ("we can't touch that").
What Salesforce technical debt actually is
Borrowed against the org's ability to change safely. A Flow that hardcodes a business rule, a field nobody is allowed to delete, a validation rule with an undocumented exemption — each made a delivery faster, and each makes the next one slower or riskier.
It is worth separating this from the two things it gets confused with. It is not "old code" — automation that works and is understood carries no debt. And it is not "bad practice" — a shortcut taken deliberately, with the trade-off written down, is a decision rather than debt.
Where it comes from
Overlapping automation
A Flow and a trigger that both fire on the same object, in a sequence nobody has documented. Each was correct alone; the interaction is the debt.
Duplicate and abandoned fields
A second field because the first was "taken", a third because the second was on the wrong record type. The abandoned ones are too risky to delete because nobody knows what still reads them.
Validation rules with invisible context
A single line of formula that quietly encodes an exception for one team, granted during one week in one year.
Undocumented decisions
The most expensive kind, because it is invisible in the metadata. The configuration looks deliberate; nobody can tell you what constraint it was designed around.
Why it is hard to measure
There is no coverage percentage for understanding. The usual proxies — number of custom objects, count of Flows, unused-field reports — tell you the size of the org, not the cost of changing it.
The honest proxy is delivery friction: how long does a small change take, how often does a change cause an unexpected regression, and how many requests stall because nobody will approve them. Those are the symptoms worth measuring, and they are all behavioural rather than metadata-based.
Impact analysis before a change
Debt becomes dangerous at the moment someone tries to build on top of it. Before changing a field or a Flow, you want to know what references it: other Flows, triggers, validation rules, formulas, permission sets, reports and integrations.
SympleOps scans objects, fields, Flows, triggers, validation rules and references before a change goes out, so the impact is visible before work starts rather than discovered in production. That single step is what converts "we can't touch that" into a scoped change with a known blast radius.
An approach to paying it down
- Stop adding to it first. Debt reduction while the same shortcut keeps being taken is a treadmill. Getting reasoning captured at delivery time is worth more than any cleanup sprint.
- Work in the path of real requests. Refactoring an area nobody touches has no payoff and high regression risk. Improve the component you are already changing for a live request.
- Make the sandbox the evidence. A change that touches a tangled component should prove itself in a sandbox with the dependent automation visible, not be argued about in a ticket.
- Delete deliberately. "We are not sure if anything uses it" is the debt talking. Dependency analysis answers it, and then removal is a normal reviewed change rather than a gamble.
- Write down the why, not the what. The metadata already documents what exists. The irreplaceable part is the constraint, the trade-off, and who asked for it.
Preventing new debt
Two habits do most of the work. The first is checking the org before building, so the change reuses what exists instead of adding a near-duplicate. The second is keeping the reasoning attached to the change, so the next person inherits an explanation rather than a mystery.
Neither is a process you can bolt on at the end. If the reasoning is reconstructed after delivery, it is already lossy.
Where durable implementation knowledge fits
The reason undocumented decisions are so expensive is that they are unrecoverable by inspection. You can read a Flow and learn what it does. You cannot read it and learn which customer escalation produced the second condition.
SympleOps keeps requirements, reasoning, approvals and artifacts connected to the work, so the context accumulates as a by-product of delivery rather than as a documentation task nobody has time for. Every approved solution also becomes reusable context for the next request.
Common limitations
- Some debt is load-bearing. A workaround that encodes a real business rule looks identical to one that encodes a mistake. Removing it without understanding why it exists is how outages happen.
- You cannot measure it completely. Anything countable — unused fields, duplicated rules, unreferenced classes — is a proxy for complexity, not the complexity itself.
- Refactoring without tests moves risk rather than removing it. Tidying code that nothing covers replaces known behaviour with unknown behaviour.
- Debt in data is not debt in metadata. Duplicate accounts and unpopulated fields are the more expensive kind, and no amount of configuration cleanup addresses them.
- Cleanup nobody owns comes back. Unless the reasoning behind new changes is recorded, the same accumulation starts again the following quarter.
Frequently asked questions
Should we refactor everything we find?
No. Debt is only worth paying down where it is in the way of something you need to do next. The rest is a list, and a long list that nobody acts on is worse than a short one that gets finished.
How do we prioritise what to fix?
Start from the next change rather than from the inventory: what does it touch, what depends on that, and what would break if the change went wrong. Impact analysis turns an unbounded backlog into a task.
Can AI find all of it?
No. It can map structure, dependencies and duplication across metadata and code, which is the measurable part. It cannot tell you that a workaround encodes a pricing decision made in 2021 — that comes from the people who were there.
How do we stop it accumulating again?
By recording the reasoning at the moment the change is made, while it is still available. Debt accumulates fastest where the why of a change is only in somebody's memory.
Where to go next
For the symptoms this produces, see Salesforce Bug Investigation and Salesforce Knowledge Management. For where the debt is created in the first place, see Salesforce Automation with AI. AI for Salesforce Teams is the category overview.
Start with one tangled component
Bring something your team avoids changing. SympleOps maps what depends on it and proposes the change in a sandbox, so the decision to touch it is based on evidence.