Key takeaways
- Salesforce technical debt is configuration and code that works today but raises the cost of every future change.
- Debt accumulates silently through admin churn, deadline builds, and acquisitions, and stays invisible until you change something near it.
- You can measure most of the debt for free with the Optimizer report, field usage data, storage usage, and a search for queries inside loops.
- Sequence the pay-down by risk and effort: fix high-risk low-effort items first, plan and fund the big redesigns, batch small cleanups, and leave stable low-risk debt alone.
Salesforce technical debt is the accumulated cost of shortcuts taken in your org: abandoned flows, hardcoded record IDs, one-off fields nobody fills, and Apex written for one record instead of many. It rarely announces itself. It shows up later as slow releases, brittle automation, and a change on one object that breaks something three objects away.
Tool vendors will happily sell you a metadata scanner before you understand what you are looking at. That order is backwards. This playbook covers how the debt accumulates, how to inventory it, how to measure it without buying anything first, and how to sequence the pay-down so you fix the dangerous items before the annoying ones.
What is technical debt in Salesforce?
Technical debt in Salesforce is configuration and code that works today but raises the cost of every future change. Concrete examples: a Flow left active after its process was replaced, a report type built on a formula field that recalculates on every row, an Apex trigger that queries inside a loop, and forty text fields where a picklist belonged.
The debt is not the shortcut itself. Sometimes a shortcut is the right call under a deadline. The debt is the interest: the extra time, risk, and coordination that every later change now carries because the shortcut was never revisited. An org can run for years on debt. It just runs slower and breaks more often as it grows.
How Salesforce technical debt accumulates silently
Three forces build debt, and none of them look like a mistake at the time.
Admin churn. People come and go. Each admin brings a mental model of the org that leaves when they do. A field named Status_2__c made sense to the person who created it and to nobody since. Undocumented automation stacks up because the next admin is afraid to delete what they do not understand, so they build alongside it instead of on top of it.
Deadline builds. A quarter-end launch ships with a hardcoded queue ID because there was no time to make it configurable. The plan was to fix it “after go-live.” Go-live passed, the next project started, and the ID is still there, now referenced by three flows. Debt taken knowingly under pressure is still debt if nobody schedules the repayment.
Acquisitions and reorgs. Merging two orgs, or bolting a new business unit onto an existing one, doubles the record types, page layouts, and sharing rules overnight. Two ways of modeling the same “Account” now coexist. Nobody planned the mess. It is the sum of two reasonable histories colliding.
The common thread: debt is invisible until you try to change something near it. That is why it needs a deliberate inventory rather than a vibe.
A Salesforce technical debt inventory
Before you fix anything, name what you have. This table is the artifact we build first on an architecture review: debt type, how it shows up in the org, and the pay-down move that clears it. Walk your org against it.
| Debt type | How it shows up | Pay-down move |
|---|---|---|
| Abandoned automation | Active Flows, Process Builders, or Workflow Rules with no clear owner; duplicate logic firing on the same object | Map every automation per object, retire the dead ones, consolidate survivors into a single Flow per object per event |
| Hardcoded IDs | Record IDs, queue IDs, or profile IDs written into Apex or Flow formulas; breaks on deploy to a new org | Move IDs to Custom Metadata or Custom Settings; reference by developer name, never by 18-character ID |
| Field sprawl | Dozens of near-duplicate fields (Status, Status_2, Old_Status); low fill rates; unclear source of truth |
Run a field usage audit, deprecate unused fields, standardize on one field with a governed picklist |
| Unbulkified Apex | SOQL or DML inside loops; triggers that fail on data loads over 200 records; recurring governor-limit errors | Refactor to bulk patterns, one trigger per object, collection-based processing; add test coverage first |
| Validation and data debt | Missing validation rules, inconsistent formatting, duplicates that block reporting and AI grounding | Detect and report with a batch scan, then remediate at source; DQS surfaces this without auto-merging records |
| Permission drift | Overlapping profiles and permission sets; access granted ad hoc and never revoked | Rationalize to a permission-set model, document who gets what and why, remove orphaned grants |
| Sharing complexity | Layered sharing rules, over-wide OWDs patched with Apex sharing; recalculations that time out | Redesign the sharing model from the access requirement up, not by patching the last exception |
| Undocumented integrations | Point-to-point API calls, unmanaged connected apps, no error handling or retry | Catalog every inbound and outbound integration, add monitoring, document the contract for each |
The point of the table is not to fix everything. It is to see the whole board before you move a piece.
How to measure technical debt before buying a tool
You can quantify most of your debt with what Salesforce already gives you, at no cost, in an afternoon.
Start with the Optimizer report in Setup. It flags unused fields, fields nearing limits, hard-coded URLs, and inactive validation rules. Then open Setup > Storage Usage and Field usage to find fields with fill rates near zero. Pull the list of active automation per object. Count the triggers per object; more than one is a smell worth investigating. Search your Apex for SELECT and insert/update keywords sitting inside for loops.
Data debt needs a different lens. Field-level completeness, duplicate rates, and format consistency are not visible in metadata scanners. This is where a batch scan earns its place: DQS runs across your objects, detects and reports the gaps across the six data-quality dimensions, and never auto-fixes or merges anything. You get the map; the remediation decision stays with you and your architect.
Only after you have this baseline does a paid metadata analysis tool add value. Buy the tool to go faster on a problem you have already scoped, not to discover whether you have one.
How to sequence the pay-down by risk and effort
Not all debt deserves the same urgency. Plot each item from your inventory on two axes: the risk it carries (does it threaten data integrity, security, or a release?) and the effort to clear it. That gives you four moves.
- High risk, low effort: do now. A hardcoded ID that will break the next deploy, or an unbulkified trigger failing on data loads. Small changes, real danger. These are the first sprint.
- High risk, high effort: plan and fund. A sharing model redesign or an integration rebuild. These need design, testing, and a change window. Put them on the roadmap with an owner and a budget, not on a wish list.
- Low risk, low effort: batch it. Deprecating forty unused fields or retiring dead flows. Bundle these into a quarterly cleanup so they do not compete with feature work.
- Low risk, high effort: leave it. A clumsy but stable layout that nobody complains about. Document it and move on. Paying down debt that costs you nothing is its own waste.
Sequence in that order and every early win reduces the blast radius of the harder work. Fixing the unbulkified trigger before the sharing redesign means the redesign runs against code that no longer falls over at 201 records.
When Salesforce technical debt means reviewing before you build
There is a threshold where cleaning up piecemeal stops being enough. If your last three releases each broke something unrelated, if nobody can say with confidence which automation fires on the Opportunity object, or if you are about to layer Agentforce or a new business unit on top of the current org, patch-by-patch repayment will not hold.
At that point the right move is an Architecture Review before the next build, not after it; our guide to the Salesforce architecture review covers what one looks like in practice. A review inventories the debt, ranks it by risk, and hands back a sequenced pay-down plan tied to your roadmap, so the cleanup and the new capability get designed together instead of fighting each other. When the debt is bad enough that a project already stalled, the same starting point applies to rescuing a failed Salesforce implementation.
Every Tucario engagement is architect-led, run by a Salesforce Certified Technical Architect, one of fewer than 500 worldwide. For orgs that need that oversight on an ongoing basis rather than a one-off, the same seat is available through Strategic Advisory, sitting alongside your team as a standing design authority.
When you do not need us: if your org is small, your automation fits on one page, and your admin already documents changes, you do not need an outside review. Run the Optimizer, work the inventory table above, and keep your own house in order. Bring in an architect when the cost of a wrong move exceeds the cost of the review.
Frequently asked questions
What is technical debt in Salesforce?
Technical debt in Salesforce is configuration and code that works now but raises the cost of every future change. Common forms include abandoned flows, hardcoded record IDs, one-off fields, unbulkified Apex, and overlapping profiles. The debt is the ongoing interest: the extra time and risk each later change carries.
How do you measure Salesforce technical debt?
Start free with the Salesforce Optimizer report, field usage data, and storage usage in Setup. Count active automation and triggers per object, and search Apex for queries inside loops. For data debt, run a batch scan across completeness, duplicates, and formatting, then buy a paid tool only after scoping the problem.
What is the difference between technical debt and functional debt?
Technical debt is under-the-hood cost: inefficient code, tangled automation, hardcoded values that slow future work. Functional debt is missing or wrong capability: features users need that the org does not deliver. Both raise cost over time, but technical debt slows delivery while functional debt limits what delivery can achieve.
Should you clean up technical debt or rebuild the org?
Rebuild only when the debt is structural, when the data model, sharing design, or integration layer is the actual problem. Most orgs pay down debt incrementally, sequenced by risk and effort. Rebuild is expensive and risky; reserve it for cases where remediation costs more than starting the affected domain fresh.
When should you get an architecture review for technical debt?
Get an architecture review when releases keep breaking unrelated things, when no one can name which automation fires on a core object, or before layering Agentforce or a new business unit onto the org. A review inventories and ranks the debt, then returns a sequenced pay-down plan tied to your roadmap.
Michał Bajdek
Co-Founder, Tucario
Co-founder of Tucario, a Salesforce consulting and product engineering firm. Works across enterprise Salesforce delivery — architecture, integrations and AppExchange products — and writes about what holds up in production.