Technical debt is something that all Salesforce orgs (and any configuration software, for that matter) will face eventually, but there are ways to mitigate it and protect your business from its negative effects. In fact, for both the 2025 and 2026 SF Ben Admin Survey reports, technical debt took the cake for the biggest challenge to Salesforce Admins. Over 50% of respondents in 2026 reported that their biggest challenge was tech debt, with the 2025 report being closer to three-quarters of respondents. This is an issue that plagues everyone indiscriminately.
This is not a definitive list, but it gives some practical ways that every Salesforce customer with orgs of any size can begin to tackle technical debt.
1. Resist Unbridled Vibe Coding
With tools like Agentforce Vibes becoming more mainstream, vibe coding is all the rage! As with any powerful tool, however, it is important that you plan and implement these tools correctly, rather than rashly.
Remember that tools like Agentforce Vibes are exactly that – tools. They are not here to replace an experienced Salesforce Developer, nor are they here to act fully autonomously in place of a Salesforce professional. They are a tool to be used responsibly by Salesforce professionals to help them to become more efficient.
The two biggest mistakes that I see when people use these AI coding assistants are publishing work that the AI has written without properly reviewing it, and using these tools to do work or write code that the user doesn’t fully understand themselves.
If you’ve read my work, you’ve heard this analogy before – you wouldn’t put someone who has never driven a car behind a steering wheel and send them on their way just because the car has some kind of autonomous driving capabilities.
These capabilities are simply a tool to help relieve the driver and help them to drive, not under any circumstances to replace a competent driver. If a car crash occurs while the driver is using the autonomous driving tool, then the driver is liable. I am sure the authorities won’t be happy that an untrained driver was at the wheel, and the autonomous driving software is no excuse!
2. Document Before You Build (Map to Business Processes)
If you’ve worked on a Salesforce build before, be it internally or as a consultant, you’ll know how important it is to document what you’ve built so that you can hand it over to the business, and the users will know how it works. What you may not have considered is how important it is to document before you build.
What I mean by this is that your documentation of the why is just as important, if not more so, than the how. You need to work with your users to clearly identify what the business requirement is, and at this stage, you need to be technology agnostic.
This means that you’re not trying to design a solution, even as simple as fields on a page. You’re simply discovering the pain points that your users face, and documenting these clearly.
These will form the basis of your user stories that you will later write, and will inform your solution design. Think about it – there’s no point building anything until you know exactly what purpose it is being built for. Documenting this clearly and tying the documentation of the problem to the solution is extremely important for now and for the future.
Businesses grow and change as industries – or the world – grows and changes. Your requirement today may be slightly different in a year’s time, and as a result, your solution may need to adapt. Sometimes it’s hard to assess a solution without knowing the intimate details of why that solution was built in the first place. Down the track, you may think something is still required when it is not, or you may remove something unnecessary that actually is necessary because no one knows the context.
This is why documenting before you build, or even start designing or redesigning a solution, is absolutely critical. It captures the business requirements, context, and pain points for future reference and makes maintenance and succession planning within that business so much easier.
3. Keep Your Finger on the Pulse
This one is a multi-parter: you need to keep your finger on the pulse within your business, across your industry, and of course across the expanded Salesforce ecosystem. If you can predict the future and prepare for it, you’re far less likely to rush into a solution and overlook accidental (or planned) technical debt while doing so.
Your users’ needs will change, and that’s to be expected. The world evolves, and a business that doesn’t die needs to as well. As their needs change, so too must their Salesforce investment to ensure it keeps serving them rather than them serving old, redundant processes that aren’t creating value anymore.
Similarly, industry changes can force rapid development that may inadvertently create technical debt. Think about this – if you work in a highly regulated industry and there is a legislative change, your business needs to adapt or potentially face negative financial consequences.
If you, as the Salesforce Administrator, are keeping your finger on the industry’s pulse, you’ll know what’s coming before it becomes an urgent issue. You can then take the lead when it comes to properly scoping the solution to ensure you can adapt to industry changes rapidly. Your business avoids being caught out, and you prove your value to the business by keeping the platform compliant.
4. NEVER Hardcode Values
You’d think this one goes without saying, but it does still happen. Hardcoded values are particularly painful because they can go unnoticed for a while, until they’re caught because of an issue. Hardcoded values are bad design, not just because they are lazy but because they can be avoided so simply – as can the related headaches.
One of the simplest and most common examples of why you shouldn’t hardcode values is as follows: If you hardcode an Id then you may run into issues during deployment. Let’s say you’re building a solution for your business that requires a new Custom Object with multiple Record Types and a Flow or two. You’re a thoughtful Salesforce Admin, so you’re doing your build in Sandbox as opposed to Production. Go you! However, you didn’t think about what may happen during the deployment, and decided to hardcode a Record Type Id.
Your Flow checks for new records in the Custom Object that use one of the new Record Types, and you’ve hardcoded the Id in the Flow. During testing, everything works well! You get your business users testing in Sandbox as well, and they have no qualms. Time to deploy to Production! However, after the deployment, you begin to hear that the functionality may not be working properly. Upon inspection, you discover exactly what’s gone wrong.
When you deployed your Record Type up to Production, it was assigned a new Id value. Your Flow is looking for an Id that doesn’t exist in Production, so it never fires. This is a simple but powerful example of why you should never hardcode values in your automations. Always consider building dynamically. Use Get Records to get the Record Type, and reference it this way instead. This ensures that it will continue to operate, regardless of which environment you are in or what the Id value is.
5. Foster a Culture of Good Architecture
I’ve seen time and time again where busy or overwhelmed Salesforce Admins will take action on a request that a user has made exactly as they’ve made it, simply because they don’t have the time to think it through properly. “Can you add a new Comments field to the Case for our team, please?” just happens to be the 25th request this week, and you’re already behind. So, without thinking it through, you add yet another field to the Case object.
This is not what your experience as a Salesforce Admin should be used for. Your job is not to take demands and implement them as business users deliver them. Your job is to ask questions, understand the need properly, understand the org as it currently stands, intimately know the industry that you work within, and design scalable solutions that meet the needs of the business as a whole.
There may be a better way to implement a solution that leads to the same outcome that is being requested. There may be a better tool, or a new angle to approach the problem that the business user is simply not aware of.
You should also document and share your learnings, as well as the reasons why you made certain architectural decisions. This way, your business can begin to understand when you ask additional questions, or don’t build things exactly the way they’ve asked. It encourages your business to think about Salesforce as more than just a “highly customizable CRM” and more as a platform that needs to be treated with respect. No rushed changes, no quick-fixes, just well-architected changes to meet business needs in a way that focuses on platform longevity.
6. Learn to Say No
This is an extension of the point above – sometimes, not only is it okay to build something in a different manner than what was requested, it’s totally acceptable to say no, and to not action a request at all. I’ve seen it so many times in my years working either as a Salesforce Admin or working alongside them as a Consultant, but sometimes saying no and not making a change is more valuable to the business than making one.
This kind of no is not a passive one – this is still taking action, despite not actually resolving the request immediately, the way the requester wanted, or even at all. Sometimes, there’s a better way to do things. Sometimes, there isn’t – and a no is totally okay there.
One example of such a request that may make sense to say no to is a team-specific Record Type and associated set of automations. Let’s say you have multiple Sales teams working together inside Salesforce, but one team wants to break the mold and do things a little differently. They may believe that they have a leg-up in terms of how effective their process is, so they want a custom set of automations just for their team.
This is one such example where it makes sense to simply say ‘no’. First off, while I admire the grit that this particular team has, it doesn’t make sense to gatekeep a process that could lead to better numbers across the board. Secondly, if you were to trial and/or adopt this new process, it doesn’t make sense to build a whole new set of Record Types, fields, layouts, etc. where an adaptation into your existing process could work better.
There’s a whole process of investigation, design, development, testing, piloting, and rolling out that makes a lot more sense. A no, but giving a representative from that team a seat at the table for design and process evolution discussions makes a lot more sense.
7. Create Space for Maintenance
As far as I’m concerned, this is one of the most overlooked and most under-respected points in this whole article, so please pay attention. Maintenance is as important as development. Maintenance is as important as new features. Ignoring maintenance for too long leads to deep pain felt throughout the entire business. You NEED to make the space for maintenance that it deserves, and you need to communicate this clearly to your business.
I say this with personal experience tugging at my heartstrings as I write this. I’ve seen time and time again in my career where quick-fixes, patchwork, and “we’ll do it properly later” cause long-term pain that creates obscene amounts of technical debt.
It stings to watch, as there’s only so much that I can suggest as an external consultant. This is why I’m putting emphasis on this, and begging internal Salesforce Admins to stand up and defend their org from this form of technical debt – the totally avoidable, and extremely painful kind.
I’ll often reference Apple in my Salesforce articles, and one such example comes to mind for me here. OS X Snow Leopard was a relatively recent and notable time when Apple decided to prioritize stability and bug fixes over new year-over-year software features. There was even a memorable slide at the Worldwide Developers Conference in 2009 that many will remember that said “0 New Features”, showcasing Apple’s promise to make performance the key focus, not shiny new tools.
Some believe this is coming at the upcoming WWDC 2026 as well, which proves my point: Maintenance is NOT once-off. Maintenance isn’t just something that happens; it’s something that deserves dedicated space, time, and attention.
Do not neglect maintenance in your Salesforce org. It is the most preventable and most toxic form of technical debt that I’ve seen time and time again. Keep on top of official Salesforce documentation, decision guides, and, of course, our distilled content here on Salesforce Ben to identify potential problems before they grow in your business.
8. “Clicks First”, Not “Clicks Only”
Just because you can do something doesn’t mean you should. Similarly, just because you can do something a certain way doesn’t mean you should necessarily be doing it that way.
I’m a big fan of Salesforce Flow, but I also know that just because I can do something there doesn’t mean I always should. Sometimes, it’s better to leverage an invocable apex method rather than nesting Loops. Sometimes it’s better to leverage a third-party screen component, as opposed to trying to get Repeaters to do what I want them to do.
I’ve always admired Salesforce’s commitment to empowering its Admins through tools that use clicks, not code, to build business workflows. The friction is significantly reduced, and the barrier to entry is all but eliminated. The barrier to mastery, however, is not. There are things that Flow simply cannot do, and some things that it can but should not.
After all, Flow was built to supplement Apex, not replace it entirely. Apex still exists today and is also getting love from Salesforce in the form of new updates with each release. Similarly, Salesforce didn’t abandon page layouts in favor of screen flows. They replaced them with Lightning App Builder and Lightning Pages. Flows can be embedded into Pages, but it doesn’t make sense to replace them fully with a single screen flow.
Always assess the challenge you’re facing, and consider every tool that you have available to you: Flow, Apex, AgentExchange, Slack… There’s a tool for everything; it’s up to you to figure out the best fit for your business and your current problem.
9. Review Permissions and How You Distribute Them
Salesforce uses a combination of different tools to grant granular access to features, objects, and records within the system. As with most things in Salesforce, there are multiple ways to approach permissions, and some ways are better (and more modern) than others.
I’m referring specifically to using Permission Sets and Permission Set Groups over Profiles. Salesforce has begun the process of decoupling permissions from profiles and encouraging the use of these new tools going forward. One key reason for this is pretty simple: You can only assign a single profile per user, but you can layer multiple permission sets and permission set groups together to achieve the structure you’re looking for.
This way, you don’t have to hope and pray that you’ll be able to give someone the right profile with just enough permission, and instead can grant access as required using a more granular set of permission sets.
For those who have had Salesforce in their businesses for a while, you may want to consider how you’ve assigned permissions in the past. You may find that you have far too many users with the System Administrator Profile due to whatever constraint required this ‘quick fix’ at the time. Consider performing a full migration of permissions away from your profiles and into permission sets and groups as soon as you can.
10. Clean Up Your Sandboxes
This one may come as a surprise, but it’s actually a bigger deal than you may initially think. If you’re done with a sandbox, maybe you should delete it. This particularly applies to developer sandbox environments that were spun up for a single task that is now well and truly complete.
You may be wondering why this is such a big deal, especially because there are quite a number of sandboxes available at any one time. There are two main answers to this: outdated metadata and security.
If you’ve got a sandbox in place that you’ve done some work in, it may seem like a quick and easy place to get started with a totally unrelated task a few months down the line. After all, it saves you the trouble of spinning up a new sandbox, right? Wrong. The sandbox that was used for a single task months ago is likely out of date in terms of what Production looks like, and is not a good starting point for new work.
Then comes security. A majority of the larger breaches we’ve seen in recent times have come from sandboxes not being secured the same way production is. New sandboxes retain different amounts of customer data depending on the type of sandbox that they are, and the customer won’t care if it was a sandbox or production environment that their data got leaked from – they’ll just be upset that you didn’t protect it properly.
Summary
Technical debt is no small issue, although a lot of it does begin as small actions taken or not taken with a short-term mindset. Always plan ahead, think strategically, and foster a culture of respect for your Salesforce investment. Rushed solutions and quick fixes lead to critical problems down the road, as does failing to prioritize the boring stuff like maintenance.
Have you experienced some technical debt nightmares? What happened, and what was the cause? Please share your stories, if you’re able to. It’s always good to learn from the wider Salesforce Ohana!
