On this page (6)
To reduce Salesforce technical debt, first inventory it: fields nobody populates, several automations firing on the same object, IDs typed directly into Flows and code, integrations calling old API versions, and packages nobody uses. Score each item by the risk it carries and the effort to fix it. Then retire it in small batches, reserving a fixed share of every release for cleanup, so the org gets simpler while new features keep shipping.
What technical debt looks like in a Salesforce org
Technical debt is the gap between how the org was built and how it would be built today, knowing what you now know. It accumulates quietly. Each admin, partner and department solves its own problem, and the fixes pile up on top of each other. None of it shows on a dashboard until a release breaks, a sandbox refresh wrecks a Flow, or a new project quote comes back double what anyone expected.
The same handful of patterns shows up in almost every org we assess:
- Unused fields and objects: custom fields with no data, or data nobody has looked at in years, still cluttering layouts, reports and every migration mapping.
- Overlapping automation: a Workflow Rule, a Process Builder process, a record-triggered Flow and an Apex trigger all acting on the same object, sometimes on the same field, in an order nobody has written down.
- Hard-coded IDs: record type, queue, user or profile IDs pasted into Flows, formulas, validation rules or Apex, which point at nothing once the metadata moves to another org.
- Old API versions: Apex classes, triggers and Flows saved on versions many releases behind, and integrations that still call versions Salesforce has retired.
- Unused managed packages: installed apps from past experiments that still add objects, permission sets, scheduled jobs and upgrade prompts.
- Duplicated reporting and access: near-identical reports and dashboards, plus profiles and permission sets cloned so often that nobody can say who can see what.
Why it matters now
Two recent Salesforce changes turned some of this debt from a nuisance into a deadline. Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025. Existing rules and processes still run, but Salesforce no longer provides customer support or bug fixes for them, and it recommends moving that automation to Flow Builder with the Migrate to Flow tool. If one of those legacy processes misbehaves today, you are debugging it on your own.
Salesforce also retired versions 21.0 through 30.0 of its SOAP, REST and Bulk APIs in the Summer '25 release. Calls to those versions now fail with errors rather than returning data. Any integration or script that went quiet around that time deserves a second look, and anything still calling versions 31.0 through 40.0 is next: Salesforce deprecates them in the Summer '27 release and retires them in Summer '28, after which those calls will fail too.
Beyond deadlines, debt makes every change slower. Each new requirement has to be tested against automation that might collide with it, and each estimate carries a margin for the unknown. That margin is the interest you are paying.
How to measure it
You cannot pay down what you have not counted. Most of the inventory can be built with tools Salesforce already provides, plus a few hours of someone reading Setup carefully.
| Debt type | How to find it | What to record |
|---|---|---|
| Unused fields | Report on how often each field is populated; use a field's Where is this used? button to see formulas, layouts and Apex that reference it | Fill rate, last meaningful use, references |
| Overlapping automation | List active Workflow Rules, Process Builder processes, record-triggered Flows and triggers, grouped by object | Automations per object, what each one updates, run order |
| Hard-coded IDs | Search exported metadata for 15- and 18-character ID patterns in Flows, formulas, validation rules and Apex | Location and what the ID points to |
| Old API versions | Check the API version on Apex classes, triggers and Flows; review the API Total Usage event log for the versions integrations call | Component or client, current version |
| Code quality | Run Salesforce Code Analyzer, which scans Apex, Visualforce, Lightning components and Flows | Rule violations by severity |
| Unused packages | Compare Installed Packages against license assignments and recent use of package objects | Package, owner, whether anyone uses it |
The API Total Usage event log is worth knowing about. It records the version, connected app and client name for each API call, so it tells you which integration is behind an old-version request instead of leaving you to guess. Without Event Monitoring the log is kept for one day, so pull it on a normal business day when every integration has run.
Put the results in one spreadsheet, one row per item, and give each row two scores from 1 to 3: risk (what breaks, or who is exposed, if it stays) and effort (how long it takes to fix and test safely). That sheet is your baseline. Rerun the same counts each quarter and you have a trend line leadership can follow.
A prioritized paydown plan
Sort the inventory by risk first, effort second. High-risk, low-effort items go first because they buy the most safety for the least time. A practical order for most orgs:
- Fix anything that is already failing or will fail on a known date: integrations on retired API versions, and legacy automation touching critical processes such as billing or case routing.
- Replace hard-coded IDs with lookups by developer name, custom metadata or custom labels, so sandbox refreshes and deployments stop breaking things.
- Consolidate automation object by object, moving Workflow Rules and Process Builder into as few record-triggered Flows per object as you can, then deactivating the originals after testing.
- Retire unused fields in stages: remove them from layouts, wait a release cycle for complaints, export the data, then delete.
- Uninstall unused packages once you have confirmed nothing references their objects and you have exported anything worth keeping.
- Raise Apex and Flow API versions as you touch each component for other work, instead of in one large, risky sweep.
Automation consolidation is usually where the biggest gains sit, and where the most care is needed. An industrial-services firm we worked with had task-creation flows that fired 30 emails at once and assignments hard-coded into the logic. Rebuilding those flows around variables, rather than fixed values, was part of the same 20-hour engagement that fixed its scheduling problems. Small, contained rebuilds like that are far safer than rewriting all of an object's automation in one go.
Paying it down alongside new work
Cleanup projects that pause all feature work rarely survive the first budget conversation. The approach that holds up is a standing allocation: a fixed share of each release, agreed in advance, goes to items from the debt inventory. The share matters less than the consistency. When a new feature touches an object, clean that object's debt in the same release, since the testing effort is already being spent there.
Pair the allocation with rules that stop new debt from forming. Require a description and an owner on every new field. Allow one record-triggered Flow per object per trigger context unless someone justifies an exception. Ban hard-coded IDs in code review. Ask whoever installs a package to name who owns it and when it will be reviewed. These rules cost minutes at build time and save weeks later.
Finally, report progress in terms the business recognizes: fewer automations per object, fewer failed deployments, shorter test cycles, and faster turnaround on change requests. A shrinking debt sheet is useful internally, but faster delivery is what keeps the allocation funded.
When to bring in help
An in-house admin can run most of this plan if they have the time. Outside help pays off when the inventory itself is the obstacle, when nobody on staff knows why the old automation exists, or when the org has passed through several partners with little documentation. A structured health check produces the inventory and risk scores quickly, and a managed services team can then work the paydown list release by release while your own people stay focused on what the business is asking for.
Questions people also ask
We need a Salesforce overhaul. What should we fix first?
Fix what is already failing or will fail on a known date: integrations calling retired API versions, and legacy automation that touches critical processes such as billing or case routing. Next, replace hard-coded IDs so sandbox refreshes and deployments stop breaking things, then consolidate automation object by object. Sort everything else by risk first and effort second, so high-risk, low-effort items go early.
Nobody understands our Salesforce customizations since the consultant left. How do we document and fix them?
Start with an inventory, not with changes. List unused fields, automations per object, hard-coded IDs, old API versions, code quality findings and unused packages in one spreadsheet, and score each item for risk and effort. A structured health check can produce that inventory quickly when nobody on staff knows why the old automation exists. Then fix items in small batches, and require a description and an owner on every new field.
Do Workflow Rules and Process Builder still work in Salesforce?
They still run, but Salesforce no longer supports them. Support ended on December 31, 2025, so Salesforce provides no customer support or bug fixes for Workflow Rules or Process Builder and recommends moving that automation to Flow Builder with the Migrate to Flow tool. If a legacy process misbehaves, you are debugging it on your own, so migrate the ones touching critical processes first.
Is it safe to delete unused fields in Salesforce?
Yes, if you retire them in stages. Check the field's Where is this used? button for formulas, layouts and Apex that reference it, remove it from layouts, and wait a release cycle for complaints. Then export its data and delete it. Always export first, because deleted metadata takes its data with it, and test the change in a full sandbox before touching production.
How do we clean up Salesforce technical debt?
Start with an inventory, then fix what is costing you most. List unused fields, duplicate automation, old workflow rules and Process Builders, and custom code with poor tests. Rank them by risk and by how much they slow down change. Work in small batches through a sandbox, retire old automation to Flow, and delete only after checking reports and integrations that may depend on an item. Then set a standing rule for approving new customizations so the debt does not return.
How do you prevent "custom chaos" in a Salesforce org?
Prevent it with a few rules. Use standard features first, and require a written reason for anything custom. Have one person or a small group approve new fields, objects and automation. Name things consistently, document why each change was made, and build in a sandbox rather than production. A regular review of unused items keeps the org clean over time.
