Technical Debt in Salesforce: A Primer

Technical debt in Salesforce is unavoidable as your business evolves — in many ways, it’s the cost of development. The longer you’ve been running Salesforce, the more likely it is that you’ve accumulated technical debt, such as unused customizations, obsolete roles and permission sets, and more.

But if technical debt is inevitable, then why is it a bad thing?

Well, to start — it isn’t always a bad thing. On its own, it’s often harmless. But if it isn’t managed properly and it builds up to the point that it slows down development, then it creates a bottleneck in your change process that hinders your team's ability to continue driving the innovation that your business counts on.

In this post, we’re taking a look at the causes of, and solutions for, technical debt in Salesforce. If you’re interested in learning more, and finding out how Strongpoint can help, check out the recent webinar we held on the topic here.

What Is Technical Debt?

Technical debt can mean a lot of things in different contexts. But in Salesforce, it typically refers to the cost of implementing ‘shortcuts' as you customize your Org.

Salesforce is a famously customizable platform, and when a user comes to you with a request, often it’s easier to create something new than to review your existing customizations to see if something can be modified or repurposed that will serve the same purpose.

This saves everyone time and solves the immediate problem, but in the long term, it can actually create more work for your team.

Don't forget to check out: Best Books to Prepare for Salesforce Certification

High Interest vs. Low Interest Debt

Salesforce Ben differentiates between two types of tech debt in Salesforce: high interest and low interest. We loved their analogy. Low interest debt is easy to pay back — it’s the things you’ve done intentionally, things you know will require rework in the coming months, but that you’ve skipped for now in order to expedite a release or speed up time-to-market.

High interest debt, on the other hand, is a lot more painful and difficult to pay back — it’s the long-term accumulation of workarounds, hot fixes and obsolete customizations that haven’t been deprecated. The rework required to fix high-interest debt might actually take more time than the initial work, which makes it harder to resolve without taking time away from other, more time-sensitive responsibilities.

The Problem With Institutional Knowledge

One of the reasons technical debt in Salesforce is so hard to deal with is that knowledge of it — and of the system in general — is often concentrated in a small team or, in some cases, a single employee. When key staff members leave, they take that knowledge with them, leaving behind a tangled web of unknown, and sometimes unfindable, code — making any change especially difficult and time-consuming.

What Does Technical Debt Look Like?

So far, we’ve talked a lot about the theory behind technical debt — why and how it happens. But what does it look like in practice? Some of the most common forms of technical debt in Salesforce are:

Excessive customization: As we mentioned above, Salesforce makes it very easy to create custom Objects and code when a declarative solution would be just as effective — think, creating a workflow instead of using a trigger for your scripts. This type of technical debt often comes from being too responsive — every change is implemented as requested, instead of finding alternative recommendations through standard configurations.

Unused customizations: As much as it’s billed as a ‘no-code’ platform, not everything in Salesforce can be handled declaratively. But changing business requirements can mean that a customization that might have been necessary at one point in time is no longer needed. Unless these customizations are deprecated they will make every new change inherently more complex, and can potentially impact end user adoption by making your Org harder to navigate.

Access controls: You’ve likely heard of the term “the principle of least privilege”. Well, on the opposite end of the spectrum, we have the principle of most privilege — users stuck with too much access as their role in the organization evolves. While other forms of technical debt can slow things down, unused profiles and permission sets are a serious fraud risk, and can impact regulatory compliance for public companies.

Tech Debt and SOX

If your Org is or will be subject to SOX, a big part of compliance is demonstrating to auditors that every change to revenue-related customizations and configuration data has been properly documented and approved. But the more technical debt you have, the less visible these changes will be.

A change connected to an unused workflow rule, for example, could be flagged by an auditor as needing to have a formal review. And when you have hundreds of unused workflows needing formal reviews, it can take weeks to produce the reports your auditors want to see.

Four Ways to Reduce Tech Debt

Plan, plan — and plan!

The most important process for avoiding the technical debt in your Salesforce Org is to acknowledge its inevitability — and plan for it ahead of time. As we’ve mentioned, technical debt doesn’t have to be a bad thing, so long as it’s properly managed. If you accept that you’ll accumulate technical debt from your releases, you can efficiently prepare for a more formal change review or backlog management procedure that will mitigate some of its negative impacts.

Check out another amazing blog by Strongpoint here: Why You Should Integrate ERP Data Into Your CRM | Salesforce Developer Guide

Change Reviews/Center of Excellence

We understand that a COE can be intimidating — but it really shouldn’t be. A Center of Excellence is all about having a formal strategy for managing change; it’s simply a baseline practice of governance that you can implement, no matter the size of your business.

If your Org is struggling to implement a formal change structure, try identifying one question that every change can be tied back to. For example, “Our goal is to support the business through A and B” or “The goal of our team is to do Y”. Each time a change is requested, refer to this statement and ensure it aligns — if it doesn’t, then you might want to reconsider.

Push back on requirements

It’s not uncommon for end users or management to request changes that sound great on paper, but don’t make sense from a development perspective. As a Salesforce Admin, you’re in a position to start discussions before completing a change you know might introduce unnecessary complexity or have detrimental downstream impacts. Remember, you’re the system expert and your opinions are valuable to the business!

Documentation

You can’t manage tech debt if you can’t find it. System documentation provides a single source of data that everyone can quickly refer to and easily understand. It’s a natural safeguard against one person or ground holding too much institutional knowledge, and it’s equally important come audit time for proving that you understand the impact of changes or deprecations.

There are many ways to collect documentation — we’ve seen everything from pen-and-paper solutions to shared Google docs — but Strongpoint is the only fully native Salesforce app that produces it automatically, tracks changes, and keeps it up to date at all times. And that’s just one of the ways Strongpoint can solve your tech debt problems!

Remember, technical debt isn't something to be afraid of. With the right tools to help guide your team and simplify your clean up processes, you can effectively manage data build-up in your Salesforce Org as it comes. Book a demo with us to learn more!