Key takeaways
- Measure technical debt with specific observations, business consequences and acceptance evidence for the fix.
- Keep unverified concerns separate from observed defects; missing evidence does not mean low risk.
- A suggested impact and likelihood index helps triage work but does not measure the health of an entire org.
- Security incidents and urgent access risks need their own escalation path, regardless of the backlog score.
Measure Salesforce technical debt by recording specific findings, evidence and business consequences, then tracking the work needed to reduce them. A useful scorecard separates confirmed problems from unanswered questions. Its dashboard shows urgent risks, owners, aging and verified fixes; a single percentage cannot explain whether the org can support your next change.
Download the Salesforce planning and debt toolkit. Replace the Debt Register’s illustrative rows with your findings. Edit the amber inputs, preserve the blue Index formulas and put a review date with the evidence. This suggested framework is not an official Salesforce rating. Its summary counts findings, unknowns and urgent open items; it does not generate historical trends.
What should a Salesforce technical debt scorecard measure?
A count of fields, flows or Apex classes tells you what exists. It does not tell you whether the design creates avoidable work or risk.
Begin with a consequence: a release repeatedly needs manual repair, an integration loses updates, or a shared business rule must be changed in several places. Capture the mechanism and supporting evidence. The technical debt overview explains how these obligations accumulate; this scorecard focuses on making individual findings actionable.
Use one row per finding. Group scanner warnings that share a cause and remediation, so scan settings do not inflate the backlog.
| Register field | Purpose |
|---|---|
| ID and affected area | Identify the finding and its system boundary |
| Observation | Describe the behavior or design actually inspected |
| Evidence, date and scope | Link to logs, tests, code or an agreed process walkthrough |
| Confidence | Distinguish observed findings from unknowns requiring investigation |
| Business impact | Describe who is affected and what happens |
| Likelihood | Describe the relevant trigger and current controls |
| Urgent override | Flag concerns that need escalation outside routine prioritization |
| Owner and next action | Assign responsibility for investigation or remediation |
| Effort and dependencies | Record delivery constraints separately from risk |
| Status and acceptance evidence | Show progress and what will justify closure |
Reference sensitive evidence in its approved location instead of copying it into a broadly shared register.
How do you separate observed debt from unknowns?
Write “no recovery test was available” when that is what you found. Do not silently turn it into “the integration cannot recover.” The first observation creates an investigation task. The second needs stronger evidence.
Similarly, an empty field is not automatically unused. It may support seasonal activity, an exception process or an external consumer. Check the relevant metadata, business owner and representative usage before planning retirement. A dependency search is one input; agree its coverage rather than treating an empty result as proof that nothing depends on the field.
Record these as separate states:
- Observed: Evidence demonstrates the issue within the stated scope.
- Unknown: A plausible concern needs testing or additional evidence.
An unknown can still be urgent. If an unanswered access question could expose sensitive information, ask the security owner to assess it promptly. Do not assign a low likelihood because nobody has investigated it.
How should you score impact and likelihood?
For routine triage, a small ordinal scale can help teams explain decisions. The following 1–3 model is suggested, not calibrated probability or a Salesforce standard. Agree examples with the business before using it.
| Level | Impact if the issue occurs | Likelihood based on available evidence |
|---|---|---|
| 1 | Contained consequence with a known workaround | Credible trigger, but not observed in representative tests |
| 2 | Material disruption to a business process | Evidence supports a plausible trigger under expected change or load |
| 3 | Critical business, service or security consequence | Recurring or confirmed trigger |
For findings with sufficient evidence, multiply impact by likelihood to create a priority index between 1 and 9. The arithmetic supports a discussion; the distance between 3 and 6 is not a measured doubling of risk.
Leave the numeric index unassigned when evidence is insufficient. The workbook shows “Needs evidence” for unknown findings. Record the investigation owner and next action instead. Keep estimated effort separate: an expensive defect does not become less consequential because remediation is difficult.
Use an urgent override for active incidents, credible serious security concerns and other time-sensitive obligations identified by the responsible owner. They follow the relevant response process instead of waiting behind a numerically higher backlog item.
What does an illustrative completed scorecard look like?
These are fictional examples showing the method. The scores are not benchmarks or measurements from a customer org.
| Finding | Evidence and confidence | Impact / likelihood | Next action and acceptance |
|---|---|---|---|
| An order update fails during a representative batch test | Test log and reproducible case; observed | 3 / 3, index 9 | Delivery owner fixes the cause; repeat the agreed batch and failure-path tests |
| Failed-message recovery has not been tested | Documentation review only; unknown | Unscored | Integration owner runs a controlled recovery exercise and records the result |
| A low-fill field may duplicate another concept | Sampled records only; unknown | Unscored | Data owner checks meaning, dependencies and representative use before recommending retention or retirement |
| A pricing rule must be edited in several components | Code references and change history; observed | 2 / 2, index 4 | Architecture owner assesses consolidation; acceptance covers consistent behavior across affected entry points |
Salesforce’s architecture patterns identify duplicated business logic and queries inside loops as design concerns. They are useful inspection prompts. Whether either pattern causes a material problem in your scope still needs investigation.
“Clean up integration” is too vague to estimate. Define the cause, action and acceptance evidence.
What should the dashboard show?
Build dashboard views from the register, with a visible scope and assessment date. Suggested views include:
| View | Decision it supports |
|---|---|
| Urgent findings and response owners | Who needs to act outside normal backlog planning? |
| Open observed findings by priority index and area | Where should routine remediation receive attention? |
| Unknowns by owner and age | Which investigation gaps are preventing decisions? |
| Findings blocking planned capabilities | What must be resolved before roadmap work proceeds? |
| Verified closures and reopened findings | Did the intervention address the problem? |
| Assessed versus unassessed areas | How much of the system does this picture actually cover? |
Keep trend definitions stable. A newly assessed integration can increase the finding count even if the org has improved elsewhere. Annotate scope changes, scanner changes and revised scoring rules so leadership does not confuse better inspection with deteriorating delivery.
Avoid an overall “org health” percentage: an average can hide serious issues, and unassessed areas supply no evidence. Summarize material blockers, unknowns and required decisions.
Which tools supply useful evidence?
Salesforce Code Analyzer inspects source code using selectable rules and reports potential issues. Record the analyzed scope, rule selection and configuration with the output. A rule finding is a starting point for review, not a complete business risk assessment.
Combine source inspection with tests, incidents and process-owner interviews. A recovery exercise may resolve an integration concern; tracing entry points can reveal the burden of duplicated logic.
Buy another scanner only when you can explain which unanswered question it will help resolve.
When should a finding be closed?
Close it when the acceptance evidence exists and the accountable owner has reviewed the result. A merged pull request alone does not prove that users no longer encounter the problem.
For the batch failure example, closure needs the agreed test results and confirmation that the fix reached the intended environment. Record remaining limitations. If the business accepts a risk, record the decision owner and review trigger separately; do not report it as a verified fix.
Connect remediation to the architecture roadmap so dependencies influence delivery order. An architecture review can help when findings span several areas and nobody can establish the cause or sequence confidently.
What should you take away?
- Record evidence and scope before assigning a score.
- Leave unknowns visible and give investigations an owner.
- Keep effort, urgency and risk separate.
- Verify outcomes before reporting debt as resolved.
An internal team can run this register without external support. If the problem is disputed priorities or missing architectural ownership, Tucario’s Architecture Review offers a defined assessment scope.
What else do teams ask about measuring technical debt?
How do you measure Salesforce technical debt?
Record each finding with evidence, its business consequence, an owner and a verifiable next action. Prioritize confirmed findings using agreed impact and likelihood criteria, while tracking unanswered questions separately.
Is there an official Salesforce technical debt score?
The scorecard in this article is a suggested local prioritization method, not an official Salesforce score. Its results depend on the scope, evidence and criteria your team agrees to use.
Does an empty Salesforce field mean it is unused?
No. A field can support an exception, a seasonal process or an external integration even when the sampled records are empty. Check dependencies, process ownership and representative usage before proposing retirement.
What should a Salesforce technical debt dashboard show?
Show urgent findings, confirmed open risks, investigation gaps, ownership, aging and closures supported by evidence. Report the assessment scope so readers can distinguish better visibility from a change in the underlying system.
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.