Salesforce Technical Debt and How to Get Rid of It
CRM tools have helped businesses get customer care and planning down to a science.
There’s a good chance that Salesforce, the market-leading CRM, powers most of your company’s most critical revenue-generating processes. But without careful planning, the ease by which Salesforce empowers you to automate these processes can leave companies hamstrung by a web of inscrutable technical debt.
With research showing that companies can burn up to 30% of their revenue on operational inefficiencies, is that something your company can afford to put on the back burner?
Technical debt and its impact on businesses
Technical debt is a term that originates from software engineering and refers to the implied cost of additional rework caused by choosing a quick and dirty—but suboptimal—solution.
In my work as a Salesforce consultant, I usually see tech debt take the form of a buildup of poorly configured processes or code in my clients’ Salesforce instance. Sometimes these processes have been tweaked repeatedly until nobody even understands their original purpose; other times, tech debt crops up over time as people change roles, and nobody has the time or know-how to clean things up that are no longer needed.
Tech debt is more than just an annoyance: in its worst forms, it can lead to considerable losses in terms of productivity, morale, and even revenue. Your Salesforce users become frustrated since they’re always running into timeouts and errors just trying to do their jobs. Your admins also become disillusioned since they spend all their time maintaining fundamentally broken processes rather than building operations that actually benefit the company.
How to spot a technical debt issue?
So, how do you know you have a debt problem? While you may encounter any number of symptoms, the top two indications are these errors: Apex CPU Timeout Error and Unable to obtain exclusive access to this record. If you see these errors frequently, you may have tech debt issues lurking behind the scenes of your Salesforce instance.
It’s important to understand that Salesforce uses a multi-tenant architecture. In simple terms, this means many clients share the same set of resources. For this reason, Salesforce needs to impose limits on the transitions their customers run to prevent any one customer from monopolizing the available resources. These ‘governor limits’ represent a limit of 10 seconds per process. If your process exceeds that 10 second run time—you guessed it—you get an Apex CPU timeout error.
The second error—Unable to obtain exclusive access to this record—is slightly different. This one usually crops up when you try to update records in your database, triggering a variety of different automations behind the scenes. When not structured correctly, these automations can trigger other automations—or even circle back to attempt additional updates to the record that triggered them in the first place. When this happens, the system temporarily locks the record you’re editing, and when you try to re-edit it, you get that Unable to obtain exclusive access to this record error.
Beyond these two symptoms, there are several other telltale signs that are indicative of a tech debt problem, including:
- Records not being updated predictably
- Limited ability to perform data loads
- Prolonged record save times
- Multiple automation tools used per object (for example, process builder, workflow rules, apex)
- Multiple automations active on the same object (for example, five process builders on the Opportunity object)
Quick ways to remove CRM technical debt
With Salesforce technical debt, I most commonly see process builder issues because it’s very easy to create dozens of different process builders and set them all live. Unfortunately, this isn’t a best practice and can result in many different processes firing simultaneously and even triggering one another until they time out.
If you think this could apply to you, I suggest trying one or more of these approaches for quick wins:
- Combine: Combine simple one-action process builders or workflow rules into a single multi-step process builder.
- Clean: Deactivate or delete actions and automations no longer being used.
- Consolidate: Group similar actions into the same process builder execution node.
- Delay: Move non-urgent updates into scheduled actions.
For the longer term, there are fewer all-encompassing recommendations since the approach differs by customer. But you should be asking yourself these questions:
- Which is the best tool for the job?
Salesforce is great at many things, but is it the best tool for evaluating complex formulas or doing real-time one-to-many updates? Consider moving heavy-duty transactions out of Salesforce and into tools like Openprise.
- Which framework is best for building and maintaining our processes?
If you don’t have a framework to build and maintain your processes, you’ll just end up with a fresh tech debt nightmare down the line.
- Can we move existing processes into flow?
Salesforce is putting a lot of resources into developing flow and is slowly encouraging users to build in flow versus process builder and workflow rules. See if you can move some or all of your process builders and workflow rules into flow. They’re supposed to be 10-20x faster!
No matter what, these projects require time, resources, and careful consideration about the approach you should take, and may signal that it’s time to think about looping in a consultant to help out.
To learn more, read about Apex CPU Timeout errors and how to prevent them from happening. Please tune in to Mr. Rey’s Neighborhood, where Rey Ong and I discuss this in detail.