Editor’s note: This post was updated on July 31, 2025, with the latest information and resources.
Awesome Admins 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 in your org? Install Org Check, a free tool from Salesforce Labs available on the AppExchange, in your org.
Once installed in your org, access the Org Check app. This app allows you to apply rules to various components in your org, analyzing things like unused licenses, missing descriptions, hardcoded ids, components with no reference in your org, and much more!
What you see below is a very short demo of Org Check. It allows you to see the rules behind the scoring, provides you a global view of your org and then from there, you can drill into the various areas to access “bad items” that should be addressed to clean your org of tech debt, and more.
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.
For the short term, identify quick wins. These are the items that are <30 minutes or 30-60 minutes for estimated effort. Items that fall under this tech debt category are relatively easy to research, clean up, and check off your tech debt remediation list, such as reviewing hardcoded Ids, adding missing descriptions, cleaning up users and permissions. 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.
2022 is coming to a close, and now is the perfect moment to look back and reflect on all we’ve learned and accomplished. #AwesomeAdmins learned a lot in the past year through some of the incredible videos, blog posts, and podcast episodes created by and for the community on admin.salesforce.com. Admin Evangelists Jennifer Lee, Mike […]
Internal teams often reach out to admins with the same types of questions, like how to reset a password, where to check their paid time off balance, or how to find a policy. These requests may be simple, but they take time and often build up during the day. Agentforce can help by automatically handling […]
At TDX 2025, Agentblazers came together to demonstrate what happens when creativity meets artificial intelligence (AI). The Agentblazer Showcase featured Salesforce Admins and community members who built innovative Agentforce solutions to solve real business challenges. Each had just four minutes to demo their use case—and they delivered. These builds didn’t just show what’s possible with […]
