Technical debt
I track the accumulated weight of every field, rule, and object that was added and never removed, because the org gets slower and more fragile with each one. The failure mode is a system so encrusted with orphaned fields and dormant automations that no one can change anything without breaking something they did not know was connected.
Technical-debt metrics are org-specific by nature; the value is the trend, not the absolute number. Anchor on whether debt is being paid down each quarter, not on hitting a universal threshold.
6 metrics
- Orphaned field rate
- Share of custom fields not referenced by any report, page layout, automation, or integration.
- unreferenced custom fields / total custom fields
- Example 900 custom fields on the Opportunity, 280 appear in no layout, report, flow, or API call → 31% orphaned. Each one still shows in field pickers and slows every admin who has to guess which field is live.
- Benchmark Practitioner finding: 20-40% of custom fields on a mature org are unused; target ongoing pruning to keep it under ~15%
- Orphaned fields bloat page layouts, confuse reps into filling dead fields, and make every schema change a guessing game about what is safe to touch.
- Dormant automation rate
- Share of automations that are active but have not fired (or serve no live process) in a long window.
- dormant active automations / total active automations
- Example Of 82 active automations, 18 have not run in 12 months, including a workflow rule tied to a retired stage; it does nothing until someone reuses that stage name and it fires unexpectedly.
- Benchmark Practitioner target near zero standing; audit quarterly. A rule that has not fired in a year is either dead or a latent landmine
- Dormant automations are latent risk: they cost nothing until a data load or a reused value wakes them up and they corrupt records nobody was watching.
- Field utilization
- Share of fields on a page layout that carry a value on a meaningful portion of records.
- fields populated on >X% of records / fields on layout
- Example The account layout shows 60 fields; 22 are populated on under 5% of records. Reps scroll past 22 near-empty fields to reach the 5 that matter, which is why they stop updating any of them.
- Benchmark Practitioner rule of thumb: a field under ~5% populated is a candidate for removal unless it has a specific low-volume purpose
- Low-utilization fields are the visible face of debt to reps; they lengthen every page and erode the discipline of keeping any field current.
- Hard-coded reference count
- Count of automations, formulas, or code with hard-coded IDs, usernames, or picklist values that break on change.
- Example A flow routes to a rep by hard-coded user ID; the rep leaves, the ID deactivates, and the flow silently faults on every matching lead until someone traces it back.
- Benchmark Practitioner target as low as possible; each hard-coded value is a break waiting for the referenced record to change or deactivate
- Hard-coded references are brittle joints: they work until the underlying record changes, then fail in ways that are slow to diagnose because the value is buried in logic.
- Deprecated component count
- Count of components on retired technology (process builders, workflow rules, old API versions, legacy Aura where LWC is the standard).
- Example The org runs 14 process builders and 9 workflow rules alongside modern flows; each is on a retired tool that Salesforce no longer enhances, and mixing them with flows makes order of execution unpredictable.
- Benchmark Salesforce has retired Workflow Rules and Process Builder for new creation; practitioner target is a migration plan with a shrinking count each quarter
- Deprecated components accumulate risk as the platform moves on; the count and its trend show whether debt is being paid down or ignored.
- Change failure rate
- Share of deployments or config changes that cause a defect or require a rollback.
- changes causing an incident / total changes
- Example 20 changes shipped last quarter, 5 broke something downstream that was not obviously connected → 25% failure rate, the direct cost of the automation and field tangle.
- Benchmark DevOps practitioner range: elite teams sit under 15%; a high rate in a CRM org usually traces to untested automation tangle
- Change failure rate is the bottom-line symptom of debt: the more tangled the org, the more often a safe-looking change breaks a hidden dependency.
01
02
03
04
05
06