Salesforce technical debt rarely announces itself as a broken feature. It appears as a field nobody can explain, three flows that seem to do the same thing, a report type that only one dashboard uses, or a deployment that takes days because nobody knows what depends on the component being changed.
Each item looks small. Together they make the org slower to understand, riskier to change and more expensive to operate.
Technical debt is not simply “old configuration,” and it is not proof that previous administrators did poor work. Much of it is a natural by-product of a changing system: a sound design can become obsolete when the platform, the business process or the recommended pattern changes.
The goal is not a perfectly clean org. It is an org whose complexity is understood, justified and actively managed.
What Salesforce technical debt looks like
Technical debt appears across several layers.
Unused or unexplained configuration
- custom fields with no populated values or recent updates;
- page-layout sections users ignore;
- validation rules disabled after an incident and never revisited;
- record types or picklist values left behind by an old process;
- reports and dashboards nobody runs;
- email templates with no known owner.
Overlapping automation
- Workflow Rules, Process Builder processes, Flow and Apex all acting on the same object;
- multiple record-triggered flows whose order and responsibilities are unclear;
- active and inactive versions with similar names;
- automation that copies data between fields because an old integration once required it.
Code and integration debt
- Apex at old API versions;
- hard-coded IDs or business values;
- tests that execute lines without proving outcomes;
- integration users with overly broad access;
- endpoints, certificates or connected apps with no current owner;
- tightly coupled triggers that make one change affect several processes.
Access debt
- permission sets created for one project and never removed;
- cloned profiles with undocumented differences;
- powerful permissions assigned “temporarily”;
- access granted directly to individuals rather than managed roles or groups.
Knowledge debt
The most expensive debt can be invisible in metadata: nobody knows why a rule exists, which team owns it or what business promise it protects. Deleting the component without recovering that context can recreate the original incident.
Why debt becomes a business problem
Technical debt competes with every new request for the same delivery capacity.
It increases:
- change risk, because dependencies and side effects are unclear;
- delivery time, because investigation must happen before implementation;
- support effort, because several layers can explain the same symptom;
- security exposure, because obsolete access and integrations survive;
- user friction, because screens and processes carry options nobody needs;
- reporting uncertainty, because duplicated fields and definitions produce different answers;
- onboarding time, because a new admin has more components and exceptions to learn.
Stakeholders rarely fund a cleanup project because “we have 900 custom fields.” They respond to consequences: releases take two weeks longer, users enter the same data twice, a stale integration holds sensitive access, or nobody trusts the pipeline report.
Tie each proposed cleanup to an outcome the business recognises.
Inventory first, but do not confuse inventory with evidence
Start by making the org visible:
- metadata type, API name and label;
- active or inactive state;
- created and last-modified dates;
- owner or responsible team;
- references from Flow, Apex, formulas, layouts, reports and integrations;
- live record counts or usage signals where available;
- package ownership;
- deployment and audit history;
- business process supported.
One signal is never enough to delete safely. A field with zero values may be new, seasonal, populated only by an integration during an annual event, or required by a report filter. An inactive flow may be the approved rollback path for a recent release.
Treat automated findings as candidates. The job of evidence is to move each candidate toward a confident decision.
Prioritise debt by impact, risk and confidence
A backlog with 600 equal-priority cleanup items will not move. Score candidates using four questions.
1. What does leaving it cost?
Consider user time, support load, release delay, licence or storage cost, security exposure and reporting confusion.
2. What is the risk of changing it?
A hidden integration dependency makes removal riskier than taking a retired picklist value off one page layout.
3. How confident are we that it is debt?
Evidence may be strong, such as an inactive flow with no references and an owner who confirms retirement. It may be weak, such as a field that appears unused but belongs to a managed process.
4. What effort will removal require?
Include discovery, stakeholder approval, sandbox testing, data preservation, deployment and monitoring—not just the delete action.
A useful first sprint contains high-impact, high-confidence and low-to-moderate-risk items. Early wins build trust for more complex refactoring.
A safe Salesforce cleanup loop
Step 1: confirm the owner and purpose
Ask who uses the component, which process it supports and what would happen if it disappeared. If nobody knows, that is a documentation problem to resolve before a deletion decision.
Step 2: trace every reference you can find
Search formulas, validation rules, Flow, Apex, reports, layouts, permission sets, integrations and documentation. Check dynamic references and external consumers that metadata search may not reveal.
Step 3: observe real usage
Use record counts, field population, flow runs, report usage, login activity and stakeholder confirmation. Choose an observation window that matches the business cycle.
Step 4: deprecate before deleting
Remove the component from the user path, stop new writes or mark it deprecated where practical. Monitor for unexpected demand. Preserve data or metadata needed for rollback.
Step 5: test in a sandbox
Run regression tests and realistic user journeys. Test integrations and bulk behaviour, not only the happy path.
Step 6: deploy through change control
Record the rationale, evidence and rollback plan. Validate the deployment and monitor after release.
Step 7: prevent the same debt returning
Update design standards, ownership fields, naming conventions, documentation or request processes. A cleanup without prevention is a recurring subscription to the same problem.
Make technical debt a standing roadmap item
Salesforce's Well-Architected Framework recommends putting technical debt in the same backlog as feature work, so it competes for capacity, and deliberately reserving capacity to reduce it. A sustainable model can be simple:
- reserve a small percentage of each delivery cycle for debt;
- review new candidates monthly;
- run a broader inventory quarterly;
- reassess legacy technology after major Salesforce releases;
- require an owner and purpose for new automation, integrations and custom fields;
- measure whether cleanup changes release time, incident volume or user effort.
The important part is regularity. Waiting for an org-wide crisis makes the eventual cleanup larger and riskier.
How orgadmin.ai helps find candidates safely
The Tech Debt Finder combines deterministic checks with an AI-assisted sweep across pulled metadata and live evidence. It can surface candidates such as unused fields, inactive flows, deprecated profiles and orphaned templates.
Each finding shows the evidence behind it and supports shared team triage. The finder does not delete anything. A confirmed candidate can be handed to the AI assistant to trace references and plan removal, after which any change follows the normal review and deployment path.
Pairing the finder with Adoption Tracker answers two different questions: does this component look obsolete, and is the feature it belongs to actually being used?
Start with the debt that blocks real work
Do not begin with the largest number on an inventory report. Begin with the component or cluster that repeatedly slows releases, confuses users or creates unacceptable risk. Gather evidence, remove it safely and measure the result.
Start a free orgadmin.ai trial to build a triaged list of technical-debt candidates from a connected org without allowing the scan itself to change Salesforce.