Every Salesforce org carries technical debt, and aiming for zero leads to worse decisions than the debt itself. The useful question is which debt to fix now, which to schedule against a known trigger, and which to leave alone. That is a governance decision. The platform owner makes it, writes it down with a name next to each item, and reviews it every quarter.
Stable debt and compounding debt
Debt accumulates for structural reasons more than through negligence: requirements arrive faster than the design can absorb them, declarative tools let more people build with less oversight, and mergers stack configuration on configuration.
What matters is whether a given item is stable or compounding. A legacy validation rule that nobody touches, on a field and a record type still in use, is stable: it costs almost nothing to carry. A Flow that fires on every Opportunity update, calls an endpoint that now returns errors and fails without alerting anyone is compounding: every run degrades data and hides an integration failure. Treat the two the same and you either waste effort on the first or let the second grow.
Complexity alone is not debt. A complex Flow for a complex business process is the right design. Debt is complexity that exists because of a shortcut. A long Apex class doing what a simple Flow could do is debt; a long Apex class handling a bulk operation that Flow cannot run efficiently is not. Refactoring working logic without a clear gain is a reliable way to add bugs while claiming to reduce risk.
Three tiers: fix, schedule, tolerate
Classify by blast radius and trajectory, not by age.
| Tier | What it is | Examples | Decision |
|---|---|---|---|
| Active risk | Degrading data now, blocking an upgrade, or creating compliance exposure | A Flow with unhandled fault paths that swallows errors; custom code that bypasses sharing rules | Fix, with a deadline in weeks |
| Latent risk | Stable today, active under a foreseeable trigger | Triggers that are not bulk-safe and hold only at current volumes; hardcoded Record Type IDs that break after a sandbox refresh | Schedule, with the plan tied to the trigger |
| Inert | Unused, untouched and harmless | Fields nobody references, permission sets assigned to nobody, report folders nobody opens | Tolerate, clean up during release windows |
An org with a long list of inert items and no active risk is in better shape than one with a short list that includes three active-risk items. Before deleting anything “unused”, check its dependencies: a field can still be referenced by a validation rule, a Flow and a shared report.
Tiers move when the platform changes. Adding Data Cloud or Agentforce re-tiers existing debt. Identity matching relies on consistent fields, so inconsistent phone formats that were inert in a standalone CRM become latent risk the day someone uses that field for matching. An agent grounded in CRM data with duplicate Accounts, orphaned Contacts and Opportunities never closed will repeat those inconsistencies in its answers, and no prompt change will fix that. Re-tier before the expansion: cleaning latent debt in a planned cycle costs less than cleaning it mid-project.
What a standard health check misses
A standard health check reviews security, counts unused fields and sorts its findings by category. A scanner will list Flows without descriptions next to Flows with unhandled fault paths; the first are inert, the second may be active risk. Tools do the discovery. The tiering takes judgement, across four layers the usual check skips.
- Automation. Execution paths, recursion, order-of-execution conflicts, governor limit exposure under normal load. Many Flows are not a risk in themselves; a handful that fire on the same update and call each other are.
- Integration topology. Every system that reads from or writes to the org, scheduled jobs and middleware included. The question is which external systems break if a field API name, a picklist or an object relationship changes.
- Data model. Schema that no longer matches the business: objects with many record types modelling several entities, circular lookups. The cost shows at the next migration or merger.
- Governance gaps. Who can deploy, whether code is reviewed, whether naming conventions exist, whether schema changes require an impact analysis. These gaps break nothing on day one. They let debt compound across teams.
Remediation order
- Stabilise. Fix what fails in production, processes close to governor limits, automations without error handling.
- Deprecations. Move off features Salesforce has announced it will retire, such as Workflow Rules and Process Builder, whose replacement is Flow. The deadline is Salesforce’s, not yours. Start with the most complex conversions: they take longer than estimated.
- Refactor. Decouple tightly coupled integrations, simplify the data model, add the controls that stop new debt. This is a standing practice with capacity set aside every quarter, with no end date.
Running the three at once creates more change than a team can absorb. Remediation also changes behaviours that users have come to treat as features, bugs included, so each wave needs its own change management.
A decision with an owner and a quarterly review
Three controls keep active-risk debt from piling up again.
- Named ownership. Every Flow, Apex class and integration configuration has an owner responsible for its health. Tie it to a role (“Service Cloud automation owner”) rather than to a person, so ownership survives turnover.
- A deployment gate. Automated checks before production: fault paths on Flows, a test coverage threshold the team sets and enforces, no hardcoded IDs.
- A quarterly debt review. A short session where the platform owner re-tiers the list against what changed: new integrations, new data sources, new agent actions. The output is a revised list with an owner and a date per item.
The platform owner signs that list: fix, schedule or tolerate. Tolerated debt then appears as a decision with a name and a date next to it. In a larger org, the Center of Excellence note covers who runs that review.
What to check
- Does every active-risk item have an owner and a deadline in weeks?
- Is every latent-risk item tied to a named trigger (volume, expansion, sandbox refresh, retirement date)?
- Has the list been re-tiered since the last integration, data source or agent was added?
- Are Workflow Rules or Process Builder processes still running, and is there a dated plan to move them to Flow?
- Who signs the quarterly list, and where is it kept?