If you’re planning an Agentforce deployment, this post is a required read before you start.

Recently, I reviewed the Technical Debt of an Enterprise’s Salesforce Instance.

We’ll clean it up after go-live. or let’s add it to the backlog.

I’ve heard this on almost every enterprise Salesforce project I’ve been part of.

It sounds reasonable. The pressure is real — timelines are tight, stakeholders are watching, and the business wants to go live. Cleaning up feels like a luxury.

But here’s the problem: technical debt in Salesforce doesn’t sit quietly in the corner waiting for you to come back to it. It compounds.

Every new feature you build on top of it inherits the problem. Every new developer who joins the org inherits the confusion. Every release cycle gets slower, riskier, and more expensive – not because the new work is hard, but because the old work is fragile.

And the worst part? Nobody can see it. Even if they see, they will ignore it.

Unlike a broken flow or a failed deployment, technical debt is invisible. It doesn’t throw errors. It doesn’t alert anyone. It just quietly makes everything harder, costlier, and slower – until one day, it breaks something important at the worst possible time.

So I decided to stop talking about technical debt and start mapping it.

Below is a Technical Debt Scoring Matrix – a framework for making the invisible visible, prioritizing what actually matters, and giving you a defensible way to have the conversation with stakeholders who don’t want to hear about “cleaning things up.”

The Problem With How Most Teams Handle Technical Debt

Most Salesforce teams handle technical debt in one of two ways.

The first way: ignore it entirely. New features take priority. The backlog grows. The org gets slower. Nobody connects the dots between the debt they accumulated three years ago and the deployment that failed last week.

The second way: do a “big cleanup sprint.” Someone raises the alarm, a sprint gets allocated, the team spends two weeks fixing things, and six months later the debt is back — because nothing changed about how decisions were being made.

Both approaches fail for the same reason.

They treat technical debt as a one-time problem instead of a permanent architectural reality.

Technical debt is not a bug. It’s a natural byproduct of building software under real-world constraints. The organization’s that manage it well don’t eliminate it – they govern it. They have a way to see it, score it, and make explicit decisions about it instead of letting it accumulate in the dark.

That’s what the matrix is for.

The Technical Debt Scoring Matrix

The matrix scores technical debt items across two dimensions:

Business Impact – How badly does this debt affect the business right now? Does it slow users down, introduce risk, cause errors, or block future features?

Remediation Effort – How hard is it to fix? How much time, skill, and risk does it introduce to address it?

Each item gets scored 1–3 on each dimension. The combination places it in one of four quadrants – each with a clear, actionable response.

Here’s the matrix:

Quadrant 1: Fix Now (High Impact, Low Effort) These are your quick wins. High business pain, low cost to fix. These should never sit in a backlog. If something scores here and it’s not being addressed in the current sprint, you need to ask why.

Examples: Recursive flow, permission sets that grant far more access than needed, hardcoded IDs in Apex.

Quadrant 2: Plan and Fund (High Impact, High Effort) These are your architectural debts. Significant business risk, but expensive to fix. They need a proper business case, dedicated capacity, and executive awareness. These don’t get fixed in a cleanup sprint – they get funded as proper projects.

Examples: A legacy Apex trigger framework that blocks modern automation adoption, a point-to-point integration architecture that needs to be rebuilt with platform events or MuleSoft, a data model designed for 50,000 records that now holds 5 million.

Quadrant 3: Batch Later (Low Impact, Low Effort) Real but not urgent. Schedule these in maintenance windows or quiet sprints. Don’t let them distract from higher-priority work, but don’t ignore them indefinitely either. They’re the broken windows of your org – small things that, left unaddressed, signal to the team that standards don’t matter.

Examples: unused fields and page layouts, redundant reports nobody runs, outdated picklist values, deprecated API versions in callouts that haven’t broken yet.

Quadrant 4: Accept or Retire (Low Impact, High Effort) The most important quadrant for honest conversations. If something scores here – low business impact, high effort to fix – the right answer is often not to fix it at all. Accept it as a known limitation, document it clearly, and move on. Or retire the feature entirely if it’s no longer needed.

This is where ego gets in the way. Architects don’t like leaving things imperfect. But spending six weeks refactoring something that isn’t causing problems – while high-impact debt accumulates  is a failure of prioritisation, not a sign of quality.

The Conversation the Matrix Enables

Here’s the real value of this exercise — and it’s not technical.

When you walk into a steering committee meeting with a list of “technical issues to fix,” you get nodded at and ignored. When you walk in with a matrix showing eight Q1 items that represent active business risk including a security vulnerability and two governor limit time bombs and a funded proposal for six Q2 items that would reduce release risk by an estimated 40%, the conversation is different.

The matrix transforms a technical conversation into a business conversation.

It answers the questions stakeholders actually care about:

“What happens if we don’t fix it?” → The impact score tells you. 

“How much will it cost?” → The effort score tells you. 

“What should we do first?” → The quadrant tells you. 

“What can we live with?” → Quadrant 4 tells you, and gives you permission to say no to low-value work.

This is what separates architects who get things done from architects who write good documents that nobody reads.

The One Thing

The insight that only became visible after mapping everything. You cannot govern what you cannot see.

Technical debt accumulates faster than most teams realize – not because teams are careless, but because every sprint that doesn’t address debt makes the next sprint slightly slower. Slightly riskier. Slightly more complex.

That slowdown is invisible until it isn’t. But the reverse is also true.

Every Q1 item you fix makes the next sprint slightly faster. Every Q2 item you fund and complete removes a category of risk from every future release. Every piece of documentation you write reduces the cost of the next developer onboarding.

The flywheel runs in both directions.

Debt compounds. So does quality.

Why Technical Debt is the #1 Blocker for Agentforce Readiness

Everyone wants to deploy AI agents.

Nobody wants to hear that their org isn’t ready for them.

Here’s the reality: Agentforce doesn’t fail because the technology is bad. It fails because the org underneath it is broken. And the things that break it are exactly the things this matrix is designed to surface.

Unclean data models. An AI agent is only as smart as the data it reasons over. Duplicate records, inconsistent field usage, objects repurposed beyond their original intent – these don’t just slow down users. They send agents down the wrong path. Confidently.

Legacy flows. Agentforce invokes actions. Those actions trigger automation. If your flow architecture is a decade of duct tape – record-triggered flows firing in undefined order, process builders still alive, conflicting automation on the same object — you don’t have an automation layer. You have a minefield.

Undocumented integrations. Agents need to call external systems. If nobody on your team can tell you what a middleware payload looks like, what the retry logic is, or whether that callout still has an active endpoint – your agent will fail in production in ways nobody predicted in the sandbox.

This isn’t a technology problem. It’s a debt problem.

Every Q1 and Q2 item on your matrix is a potential Agentforce failure mode waiting to happen. Teams that clean these up first don’t just have better orgs – they have deployments that actually stick.

Run the matrix before you run the agent.

→ Not sure if your org is ready for Agentforce? Start with the Agentforce Reality Check.

_________________________________________________________________________________

What’s the biggest source of technical debt you’ve seen in enterprise Salesforce orgs? Drop it in the comments.