As #AwesomeAdmins, you wear many hats. You’re busy working on the newest enhancements, managing and training users, ensuring your org is secure, troubleshooting issues, maintaining the org roadmap, and working the backlog. Essentially, you’re the keeper of your org. You also need to perform periodic reviews and spring clean your org, as needed, to ensure it’s in top shape.
You know best that there are many ways to build in Salesforce. When you’re juggling multiple tasks and pressed for time to deliver (and believe me, we’ve all been there), you pick a solution, build it, and move on to the next task. While having options when building in Salesforce is certainly a good thing, there’s also a downside. Why? Consider the following scenario.
Imagine you’re on a hike and you come upon a fork in the road. You know that both paths lead to the same destination, but which one should you take? One path, although longer, has multiple opportunities to stop for water, places to rest, and is less rigorous on your shoes. The other path is shorter but much narrower, steep in some areas, and requires you to climb rocks — your shoes will be pretty roughed up and need to be replaced.
Regardless of which path you take, you still achieve the same end result (you reach the destination). However, one gets you there faster but is not sustainable, and the other takes longer but is easier on the feet overall. The same dilemma applies to solutions in your org. While they may achieve the same end goal, some solutions are better than others. And, by choosing just any solution, you may be incurring tech debt on your org as a result.
Wikipedia defines technical debt (also known as design debt or code debt) as “a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. As with monetary debt, if technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes.”
Let’s bring this Wikipedia definition to life by elaborating on our hiking example. Imagine you’re prepping for your trip and need to bring your eyeglasses and sunglasses with you. You go to the store, but which ones do you purchase? Do you get three pairs — a pair of eyeglasses, a pair of sunglasses with prescription lenses, and another without (because sometimes, you wear your contacts)? Or, do you buy a single pair of glasses with removable lenses — regular prescribed lenses, prescribed sunglass lenses, and regular sunglass lenses?
Given the choice, I would select the latter as it’s only one thing I’m bringing on my hike. Think of the individual glasses as the easy design. The glasses have a similar structure, but the main difference is the lens. Now, think of the other design with the interchangeable lenses as the better approach. This design took longer to build, but the lenses are configurable building blocks, which allows the customer to re-use the glass frame again and again. If the company comes out with a new lens, I don’t need to buy another pair of glasses, I just buy the new lens.
Choosing the glasses without the interchangeable lenses just for the purpose of hiking would mean you had to revisit the types of glasses you need for other activities. Not to mention, they likely need replacing more often, especially if they get damaged or lost — or you simply want a new style. Similarly, in terms of your org, I would further extend the tech debt definition to include the cost of org maintenance for configuration, as well as code that’s outdated or no longer used.
Here are some examples of tech debt that you may find in your org over time:
Now, tech debt isn’t inherently bad. However, much like financial debt, it could potentially lead to serious problems if you don’t pay it back. Choosing the easiest and quickest solution over the best solution is a short-term fix. And, in the long term, you may incur more cost and spend more time maintaining or enhancing that quick, easy solution. Leaving configuration or code that is no longer used in your org is like leaving dirty or old laundry laying around. It doesn’t hurt anyone, but it adds to the clutter and, ultimately, becomes time-consuming and requires major effort to clean up later.
How do you find the outdated or not utilized components outside of combing your org manually? Salesforce Optimizer to the rescue! Optimizer is a native app that evaluates your Salesforce org to determine how your company uses its features and provides recommendations to optimize feature usage, including ways to simplify customizations and drive user adoption.
To enable Optimizer, search for “Optimizer” in Setup, click Allow Access, read and agree to the terms, and click Save and Close to enable access to the app. Open Optimizer to access the Optimizer App. Select Run Optimizer to run the metrics the first time. Depending on the size of your org, this can take up to 24 hours to complete. You’ll receive an email once the results are available for review. Note: You can schedule Optimizer to run the metrics monthly or on-demand. Once the metrics are generated, you can review them interactively and take action to remediate the items. You can also find apps on the AppExchange that can help you identify tech debt.
Given there are many ways to build in Salesforce, how do you know which solution provides the best or most optimal design? It comes with knowledge and experience. The solutions I built when I was a new admin are not necessarily the same solutions I would build today, nearly a decade later. Nor are the features available today on the platform the same as 10 years ago.
The capabilities of the platform and your own knowledge evolve over time. You learn best practices via Trailhead or from experts, by attending webinars and conferences, and by sharing knowledge with your peers and those with more experience. I recommend doing peer reviews, where you explain the requirements and review your solution with a colleague or someone more senior. A key benefit of peer review is the opportunity to learn about a solution you hadn’t even considered or features you weren’t aware of.
The phrase “pay me now, or pay me later” comes to mind when thinking about tech debt.
I recommend coming up with two plans: one to address items sooner and another to address items later.
Here’s where the metrics from Optimizer come in handy. Review the items by Estimated Effort and those requiring action (Status = Action Required, Immediate Action Required, or Review Required). Select the feature link to drill into the item to learn more.
Once you drill into the feature, Optimizer gives you guidance with (1) a summary of the results, (2) a list of all the items for review, (3) recommendations on level of effort and what actions to take, and (4) helpful resources to learn more about the topic and how to remediate.
For the short term, identify quick wins. These are the items that are <30 minutes or 30-60 minutes for estimated effort. They are relatively easy to research, clean up, and check off your tech debt remediation list. Tackle a couple of them in each sprint.
There will be tech remediation that takes longer to research or implement the changes for. Bandwidth is tight — I get it! In those cases, you may decide to follow the famous saying, “If it ain’t broke, don’t fix it.” I’ve taken that approach myself with migrating workflow rules and processes to Flow.
But, if you’re enhancing automation and that automation was created using old workflow rules or processes, you should consider taking the additional time to refactor solutions using new, performant technology. That way, it doesn’t become a major undertaking since you’re breaking down the work into smaller pieces to be delivered over time.
Taking the approach of “kicking the can down the road,” or holding off on remediating any tech debt, can have negative consequences. You may run out of runway, and the cost to address the tech debt can become more expensive the longer you wait. For example, if you continue to build on your existing, non-scalable architecture, any new enhancements may make it harder to peel back later. You also need to recognize implications to the security and overall health of your org. Are you depending on other features that are no longer supported or aren’t as performant? Are enhancements becoming too costly, impacting delivery? Are you unable to scale your operations?
Consider adding the longer-term items to your backlog and chipping away at it with each sprint until it’s addressed. This way, it’s less overwhelming to remediate tech debt.
Give your org some love. If components or solutions in your org do not spark joy, remove them. Clean up that tech debt! Who doesn’t feel a sense of accomplishment and pride after their org is nice and tidied up?
#AwesomeAdmins, we’d love to hear about how you’ve found and addressed tech debt in your org, or about one piece of tech debt you really enjoyed paying off. What measures have you taken to keep that tech debt low or squash it all together? Tell us what has worked well for you by tweeting us @SalesforceAdmns using #AwesomeAdmin.
As a Salesforce Admin, you play a crucial role in maintaining the security of your company’s valuable data. In fact, security is one of the five admin core responsibilities. New technologies like GenAI and Salesforce’s Agentforce bring increased value to admins, but also new security challenges. Following security best practices is more important than ever […]
Over the past decade, the Salesforce Admin role has undergone a remarkable transformation, evolving alongside the platform itself from a simple CRM tool to a robust business ecosystem. As Salesforce has grown, so too has the significance and complexity of the admin role, making it one of the most critical positions within any organization leveraging […]
It’s possible by now you’ve been to a Salesforce event or went through some Trailhead modules, and you’ve built your first agent in Salesforce. What’s even more possible is that you know about artificial intelligence (AI) and have in some way been involved in company discussions about its use. For me, those types of discussions […]
