Editor's note: This guide draws on 1,000+ Salesforce technical debt audits across mid-market and enterprise orgs. The pattern numbers (29% Apex coverage, 15 post-EOL Workflow Rules, 418 unused custom fields, 1,844 inactive Flows) are median findings.
TLDR
- 29% Apex test coverage is the median for 4-year-old mid-market orgs. Salesforce requires 75% to deploy.
- 15 post-EOL Workflow Rules still firing is the typical Spring 2024 deprecation debt.
- 418 unused custom fields and 1,844 inactive Flows clutter the metadata graph in a typical org.
- Six domains measure technical debt: Apex Classes, Apex Triggers, Flows, LWC Components, Workflow Rules, Metadata. Each gets an A-F grade.
- Salesforce Well-Architected is the canonical framework. Map findings to it for architect and CIO consumption.
What technical debt actually means in Salesforce
In application development, technical debt means accumulated suboptimal choices that slow future work. In Salesforce, it means six specific patterns:
-
Apex governor risks. SOQL inside loops, DML inside loops, hardcoded IDs, classes without explicit sharing, queries without limits. Code that runs fine on 10 records but trips governor limits on 200.
-
Test coverage gaps. Apex classes below the 75% deploy threshold. Tests that pass individually but fail in suites. Classes with no test coverage at all. Coverage that drifts down as new code lands without tests.
-
Multi-trigger anti-pattern. Multiple Apex triggers on the same object. Race condition risk. The "one-trigger framework" is the canonical fix and most orgs we audit do not have it.
-
Post-EOL automation. Workflow Rules and Process Builder processes deprecated by Salesforce in Spring 2024. Still active in production, still consuming CPU, still competing with the Flows that should have replaced them.
-
Dead metadata. Custom fields never populated, custom objects with zero records, Flows in Draft status, layouts referenced by no records, profiles with no users. Each costs metadata space and obscures the architecture.
-
Undocumented ownership. Flows, Apex classes, and custom fields with blank Description, no owner attribution, no documented purpose. The teams that built them are gone; the artifacts persist.
The six domains all compound. The org with 29% Apex coverage usually also has 15 post-EOL Workflow Rules and 418 unused fields because the underlying root cause is the same: no continuous hygiene practice.
How technical debt manifests
Three operational signals tell you the debt is real:
Signal 1: Deploys fail more often. Apex test failures during validation, governor limit warnings, dependency conflicts. The pre-deploy validation step takes longer each quarter because there is more debt to navigate around.
Signal 2: New features take longer. Adding a custom field requires checking 50 existing fields to avoid name conflicts. Adding a Flow requires understanding the existing 282 automations on the object. Adding an Apex class requires reading legacy code that lacks documentation.
Signal 3: Onboarding new admins is painful. New hires need 8-12 weeks to understand the org instead of the 2-4 weeks it should take in a clean org. The unfamiliarity persists because the org itself is unfamiliar to anyone.
The audit catches the underlying cause of all three.
The six domains in detail
Domain 1: Apex Classes
What gets measured:
- Total class count
- Test coverage per class
- Governor risk patterns (SOQL in loop, DML in loop, hardcoded IDs)
- Sharing model (with sharing, without sharing, inherited sharing)
- Code smell density (long methods, duplicated code, complex conditionals)
Median findings:
- 567 Apex classes
- 29% test coverage average
- 14 classes with SOQL in loop
- 9 classes with DML in loop
- 11 classes using
without sharingwithout justification - 8 classes with hardcoded record IDs
Grade thresholds:
- A (90+): 80%+ coverage, zero governor risks, clean sharing model
- B (75-89): 75%+ coverage, minor risks
- C (60-74): 50%+ coverage, some governor risks
- D (40-59): Below 75% coverage, governor risks present
- F (under 40): Critical risks, code unsafe to deploy
Domain 2: Apex Triggers
What gets measured:
- Number of triggers per object
- Adherence to one-trigger framework
- Bulkification
- Recursion handling
- Trigger handler test coverage
Median findings:
- 1.4 triggers per object on average
- 8 objects with multiple active triggers (race condition risk)
- 2 cases of trigger recursion (max depth)
- 3 triggers without bulkification
Grade thresholds:
- A: One trigger per object, all use handler framework, fully bulkified
- F: Multiple triggers per object, recursive paths, single-record patterns
Domain 3: Flows
What gets measured:
- Active Flow count
- Subflow call depth
- Documented ownership (Description field)
- Inactive draft Flows in metadata
- Flow performance patterns (Get Records in loops, etc.)
Median findings:
- 144 active Flows
- 1,844 inactive Flows in metadata
- Avg subflow depth: 2.8
- 67% of Flows missing documented owner
- 11 Flows with Get Records inside loops
Domain 4: LWC Components
What gets measured:
- API version (current vs deprecated)
- Accessibility attribute coverage
- Test coverage (Jest)
- Bundle size and load performance
Median findings:
- 23 LWC bundles
- 4 using deprecated @lightning APIs
- 3 missing accessibility attributes
- 94% on current API version (LWC is usually the healthiest domain)
Domain 5: Workflow Rules
What gets measured:
- Active Workflow Rule count (every active one is post-EOL debt)
- Field updates per rule
- Equivalent Flow that should replace each
Median findings:
- 15 active Workflow Rules (median, mid-market)
- 47 total field updates across them
- All 15 have a documented Flow equivalent path
Grade thresholds: Workflow Rules are universally graded F because Salesforce deprecated them.
Domain 6: Metadata
What gets measured:
- Unused custom fields (zero references in code, layouts, reports, validation rules)
- Inactive flows still in metadata
- Profiles with zero users
- Orphan layouts (referenced by no records)
- Component-to-component dependency graph health
Median findings:
- 418 unused custom fields
- 1,844 inactive Flows still in metadata
- 12 profiles with zero users
- 23 orphan page layouts
Salesforce Well-Architected mapping
Salesforce Well-Architected is the official architecture standard published by Salesforce in 2023, defining best practices across five pillars: Security, Performance, Reliability, Scalability, Maintainability.
The Technical Debt Audit maps each finding to a pillar:
| Domain | Well-Architected Pillar | Specific Finding Examples |
|---|---|---|
| Apex Classes (governor risks) | Performance + Reliability | SOQL in loop violates Performance |
| Apex Triggers (multi-trigger) | Reliability | Multi-trigger causes race conditions |
| Flows (subflow depth) | Maintainability | Deep nesting hurts comprehension |
| LWC (API version) | Performance + Maintainability | Deprecated API will break |
| Workflow Rules (post-EOL) | Maintainability + Reliability | Deprecated, must migrate |
| Metadata (dead components) | Maintainability + Scalability | Clutter slows everyone down |
This mapping makes the audit findings auditor-defensible at the architect level.
The cleanup playbook
Six weeks of focused work moves the typical org from D grade to B grade. Here is the standard sequence:
Week 1: Apex test coverage backfill
- Identify the 30 highest-impact uncovered classes
- Generate test scaffolding with the AI agent
- Human review and approve each
- Run the test suite; verify 75%+ coverage per class
Week 2: Governor risk fixes
- Refactor SOQL-in-loop patterns to bulk queries
- Refactor DML-in-loop patterns to record collections
- Replace hardcoded IDs with Custom Settings or Custom Metadata Types
Week 3: Workflow Rule migration
- Map each active Workflow Rule to its Flow equivalent
- Build the Flow in sandbox
- Validate identical behavior
- Activate Flow, deactivate Workflow Rule
- Repeat for all 15
Week 4: Multi-trigger framework migration
- For each object with multiple triggers, design the consolidated trigger + handler structure
- Refactor existing logic into handler classes
- Test in sandbox
- Promote to production
Week 5: Dead metadata cleanup
- Identify safe-to-remove custom fields (zero references)
- Mass-deactivate Flows in Draft status
- Remove orphan profiles and layouts
- Re-scan to confirm
Week 6: Documentation backfill
- For every active Flow without Description, write a one-line purpose statement
- For every Apex class without comments, add a header block
- For every custom field on the Account/Lead/Opportunity objects, document the business meaning
The end state is not perfect. It is significantly better. Grade B is the realistic target. Grade A requires year-over-year discipline.
How much can the AI agent do?
For the cleanup work above:
- Apex test scaffolding: 70% agent-generated, human-reviewed
- Governor risk refactoring: 50% agent-generated, human-reviewed
- Workflow Rule -> Flow migration: 60% agent-generated, human-validated in sandbox
- One-trigger framework: 40% agent-generated boilerplate, human-architected logic
- Dead metadata cleanup: 90% agent-identified, human-approved bulk-remove
- Documentation backfill: 50% agent-suggested, human-edited for accuracy
The agent does the tedious work. Humans do the architectural decisions. End-to-end time: 6 weeks with the agent, 4-6 months without.
The cost of not cleaning up
Three real costs:
Cost 1: Velocity decay. New feature delivery slows 30-50% in heavily indebted orgs. The team spends more time understanding the existing org than building new functionality.
Cost 2: Implementation premiums. Consulting partners charge premiums to work on indebted orgs because the discovery work is longer and the change risk is higher. Typical premium: 30-100% over clean-org rates.
Cost 3: Failed AI rollouts. Agentforce and similar AI tools fail to deploy or hallucinate in production when run on top of debt-heavy orgs. The AI readiness score (which is heavily influenced by technical debt) is below threshold.
The Technical Debt Audit produces the data your CIO needs to budget for cleanup before any of these three costs hit.
Common questions
Q: How is this different from Salesforce Optimizer?
Optimizer is a free static PDF of generic recommendations. It does not grade per-domain, does not measure test coverage, does not detect governor risks at the source level, does not propose migration scripts. Our Technical Debt Audit does all four.
Q: Can the audit fix issues automatically?
For specific patterns (test class generation, simple Workflow Rule -> Flow migrations, dead metadata cleanup): yes, with human approval on each. For complex architectural decisions (one-trigger framework refactoring, governor risk pattern fixes): the audit proposes the fix, the human architect approves and adapts.
Q: How often should the audit run?
Continuously for orgs at C grade or worse. Quarterly for B grade orgs. Annually for A grade. The Clientell agent runs incremental scans daily.
Q: Does this work for managed packages?
The audit reads your custom code and configuration. Managed package internals are not modifiable and are excluded from grading. Package usage statistics (which packages are actually used) are included.
Q: What about Salesforce Industries Cloud (Vlocity)?
Vlocity adds DataRaptors, OmniScripts, and Integration Procedures as additional artifact types. The current audit covers Salesforce-native artifacts; Vlocity-specific grading is roadmap.
Q: Will this break anything?
The audit is read-only. Findings are read-only outputs. Cleanup actions are sandbox-tested before production. The agent does not auto-apply changes; every action requires human approval.
What to do this week
-
Run the free Technical Debt Audit. 10 minutes. Get your A-F grade per domain.
-
Pick the lowest-grade domain. Usually Apex Classes (test coverage) or Workflow Rules (post-EOL migration).
-
Sprint 1: backfill 20-30 highest-impact items in that domain. Aim for one-letter-grade improvement.
-
Run the audit again. Confirm the grade lift.
-
Repeat for next domain. Six weeks gets you from D to B average across all six.
The teams that treat technical debt as ongoing hygiene compound the savings year over year. The teams that wait until external pressure (audit, AI rollout, acquisition) face the same debt but on someone else's timeline.
Run the Technical Debt Audit first. Cleanup follows.
