When I started my Salesforce career back in 2013 as an unsuspecting admin, I was given full license by my SMB employer to do whatever I wanted with their fancy new Enterprise org investment after their implementation consultants left. This was an exciting prospect as a 23-year-old techie who loved automating things and finding creative ways to bring value to my company. Let learn about Tech Debt The Silent Org Killer.
What I didn’t realize was that I was on my way to amassing a lot of something called technical debt. Every new field I made, every AppExchange app I installed, every Apex trigger I cooked up….all became cogs in the massive machine of our Salesforce org that would either become part of the critical path for our daily operations, or become entirely useless and obsolete over time (or from the get-go, if never truly implemented). And I would be the only one who knew how they all worked together.
And of course, this was all in Production. Sure, we had a Sandbox, but is the effort of keeping those environments in sync really worth it? And moving everything over in Change Sets is SUCH a pain…
Well, after a few years, I ended up leaving that employer for a larger company (one where we were much more scrupulous about release management), and that old org was left to collect cobwebs in the state I’d left it in (with me occasionally moonlighting to address small issues). Eventually, that company would phase out their Salesforce in favor of NetSuite, which was perceived as easier to use and manage than what they had experienced from our particular Salesforce implementation.
Looking back, after working on larger orgs as an architect and a consultant, I can easily see the errors of my ways. And it wasn’t that I was negligent…I just didn’t know better. The hindsight of experience has left me knowing that a few key principles would have kept me on track to manage my tech debt and better prepare my org for long-term
maintenance:
- Set realistic expectations with stakeholders (and yourself)
- Embrace change and release management
- Go custom as the exception, not the rule
- Self-document with descriptions and separate concerns
- Keep your eye on the gotchas
I know there are many out there like me who, eager to please management and make the magic happen, deliver innovative-but-half-baked solutions that get the job done short-term but end up poorly documented and difficult-to-maintain long-term. By thinking though these principles, you are much more likely to feel less guilty leaving the work you’ve wrought in your org to the next unsuspecting admin.
Set realistic expectations with stakeholders (and yourself!)
A lot of things in Salesforce are easy to do by nature. After a few Trailheads, you can be point-and-clicking your way to a very snazzy application in no time. And that will inevitably get a creative-minded app builder’s mind going about all the possibilities for your organization.
But is it worth your time, right now, to build that thing, and keep it going? What else is a priority?
Before building anything substantial, always go to the business leads of impacted teams first to confirm their priorities before going full steam ahead. Everyone has their pet projects, but that doesn’t mean it’s the most valuable thing to build, right now.
If there’s something you or business stakeholders really want out of Salesforce, offer to make a POC (proof-of-concept) in a sandbox and demo it to the team. If there is a clear need for what you show off and it gets them excited, offer to build it in a defined period of time (give yourself lots of buffer room!), and get their buy-in to pilot the functionality and support the rollout (including bugs in the aftermath). That way, you know your work will not become shelfware and the team is invested in the outcome.
Embrace change and release management
When you are in charge of a shared application, your work has a significant impact on the daily work experience of multiple individuals on the team, each with different thoughts and opinions. And when you make a change to that experience, you can bet that those individuals will have something to say (and maybe not to you, but to their teammates and bosses).
A great way of circumventing the frustrations of unsuspecting business users is to involve them in the development process as much as possible, but in a structured way. Using a tool like Jira to manage upcoming changes, organize them in a roadmap, and broadcast them widely is the key to keeping your organization aligned with what is in the pipeline.
Even if you don’t have a sophisticated DevOps process, you can still do release management if you are tracking your changes and deploying them in collective batches. The stories and bugs you track can be documented as release notes out to your team, so they know what will be different the next time they log in, and what new features and bug fixes are ready to try out.
At the end of the day, it doesn’t matter what tool you use to track your changes or releases. As long as you are comfortable with owning the process of tracking them, and you can stay consistent, you’ll be providing yourself and your team more visibility into how your org is changing, and more agility in addressing unexpected issues when they inevitably happen.
Go custom as the exception, not the rule
With a platform as customizable as Salesforce, it is easy to look at it like a canvas ready to be painted. But the fact of the matter is, it’s more like a coloring book, with lines already printed on the page for you to fill in. Do you really want to draw another image on top of that? Won’t that create kind of a mess?
Sure, out of the box, Salesforce is not as developed of a platform as other CRM or business software that have more industry-focused use cases; it does take some customization to get it to work for your business processes. But that doesn’t mean you shouldn’t do your due diligence for understanding the Salesforce status quo, and break out of the mindset that your organization is entirely unique in its business processes.
All I’m saying is: take some time to look at all the objects and tools that are provided in Sales and Service Cloud. Consider what their intended use cases are. Look at Trailhead modules and analyze why the data model is set up in the way that it is. Don’t re-invent the wheel; leave the custom objects and fields for when nothing in the standard data model will suffice (though it is worth researching whether certain standard objects, like Tasks, Contracts, or Orders, have limitations that make them difficult to use). Always see if you can enhance something existing (e.g. a standard picklist) rather than create something new (though sometimes you really need that sub-type or approval status field).
Your customizations should always have a clear connection to an obvious business functionality, and fit in the overall context of the application. Just like coloring within the lines!
Self-document with descriptions and separate concerns
Documentation is always going to get put off; it’s a fact. It’s basically the flossing of the software development world.
But, there’s way of documenting without writing a long document that no one may ever read. By writing thoughtful descriptions for components, you are always giving yourself (and anyone who comes after you) a leg up in understanding why that thing exists, and its surrounding context.
And, you can keep updating that description as the component changes. For example, if a component is no longer in use, you should always note “deprecated” (NOT depreciated; they are different!) to indicate that it is no longer in active use, even if it can’t be deleted permanently. This can also often be done in the label of the component (especially for fields and objects), though keep in mind that this will be more visible to users than a description.
In addition, when building automations, applying the concept of “separation of concerns”, i.e. putting a specific operation in separate components or functions that are clearly labeled, will make your processes and code more readable at a high-level, without the innate context you have as its creator. And reading naming conventions and
best practices when it comes to both declarative and programmatic automations will make the lives of whoever ends up maintaining your Rube Goldberg machine a lot easier.
Keep your eye on the gotchas
Of all the things I’ve listed, this is the most important. You can’t expect perfection out of any software platform or implementation, and Salesforce is no exception. New features always take some time to have their quirks worked out (remember the Lightning Experience rollout?), and since the platform is updated three times a year, you always have to stay aware of what is changing, both for the enhancements that may make your life easier, and the deprecations that will make it harder.
Salesforce is pretty good about supporting their platform functionality long-term, but finding the sweet spot of early-or-late adopter that works for you is key to staying on top of unexpected issues. And if you ever run into issues, you have the Trailblazer
Community and tons of other resources available to you to help you diagnose your issues. And if you find a solution, be sure to make a note of it! Whether it’s your change tracking solution, or a description or code comment, make it clear that you put some thought into what you built and explaining the why. And don’t be afraid of leaving a TODO: here or there so people know what you wish you could fix, but couldn’t at the
time.
Technical debt can be a scary thing to think about, but by applying the principles above in your day-to-day, you will gradually pay down that debt and make using Salesforce easier for yourself and everyone else that touches it.
