• KrazyTech Team

Tackling Technical Debt: a Guide for Salesforce Admins

Starting a new job can be challenging. Starting a new job and learning Salesforce for the first time can be a bit more difficult. If that org is 10+ years old and filled with undocumented custom code and various customizations, that can be even tougher. This is a situation that many new admins find themselves, even if they are fortunate to have the prior admin show them the ropes as you ramp up.

As Salesforce orgs continue to be developed, technical debt can impede admins from taking advantage of all the greatness Salesforce releases have to offer. Salesforce intends to make administration easier, however with technical debt relatively basic functionality becomes tangled up, for example in outdated triggers and packages. A quick Google search of ‘Technical Debt’ will provide you with an endless list of definitions. For this article, I define ‘Technical Debt’ as the accumulation of configurations (eg. code, fields, or declarative functions) that hinder the development and ongoing maintenance of a Salesforce org. If you are interested in a broader view of technical debt and its background, you can also check out this article. For a team, technical debt can be challenging – for a new admin, it can be utterly overwhelming. Here are some practical steps a new admin can take to get more comfortable with chipping away at a mountain of technical debt.

1. Prioritize

Understand the technical layout of your org to prioritize your decision-making by highest impact items. Every org has a laundry list of To-Do’s or items on their roadmap they would like to tackle. The sheer vastness of an org can make it difficult to begin, but taking time to go through your objects, apex, packages to understand the technical layout and combining that with user interviews can give you an overview of the backend and user experience. If you have no clue where to begin, a great starting place is leveraging the Salesforce Optimizer app and examining how those results layer into org-wide goals. For example, if you are getting results about too many workflow rules and apex triggers, you can tell that process automation will be a focus. Prioritizing your decision-making by highest impact and phasing your approach can then make it less daunting.

2. Refactor

Do you have ancient triggers? What you will notice is that a large amount the logic triggers were needed for many years ago can now be built with declarative tools. While Flow logic still has some gaps, Salesforce Flow is definitely a powerful tool we hear about every release cycle.

Source: Record-Triggered Automation Decision Guide by Salesforce

Above is example documentation of trigger use cases (and when to use each) based on ease of implementation and maintanance (including cost). While some may shy away from this type of documentation, I feel it is crucial that admins, even the new ones, have a strong understanding of these tools. The last thing you want to do is spending hours building process builders and the time it takes to save an opportunity record quadruples.

3. Partner

While you should own the process, getting help is an important part of the process. There are hundreds of Salesforce consulting partners that offer their expertise to Salesforce customers, working effectively alongside the internal Salesforce admin. The crucial piece is finding a consulting partner that is right for you. Please do brace yourself to sit through many presentations with words ‘data’ and ‘empower’ (and those MC Escher powerpoint backgrounds!) Additionally, feel free to ask yourself questions such as: can you see this partner being able to teach you as they help you (being a new admin yourself), or will they simply complete the job and walk away? Will they push back on your plan, or simple execute a task without advising on best practice?

4. Documentation/Time

This is the part you were dreading I would mention. When it comes to documentation, set your expectations and devote time. Devote a lot of time. No matter the money and resources you toss at these situations, your consulting partner will never have the insight you have on your org. Your duty is to build out documentation, or revamping existing documentation, to be fully comprehensive. Understand your many fields and how triggers/classes/tools interact with each. Furthermore, see if those fields are even being used or populated anymore. From there, I would even go as far to say that developing a rudimentary understanding of Apex can help here to at least have a rough understanding of how those components interact. How Salesforce documentation can defend your org against technical debt is also covered in this article. Oh, and while you are here, invest in a good coffee maker.

5. Cover Yourself

A common feeling for a new admin is deleting some code (trying to do the right thing) only to get an irate email from a VP of Sales that they can’t close their opportunity and are getting a paragraph long error message. There are some easy steps to mitigate this reaction. Firstly, backup your org information before deleting or changing anything. This can be in the form of sandboxes, local copies, or by using a third-party backup tool.

  • If you are concerned, take multiple steps, back it up, and have redundancies.

  • Once you feel confident your information is properly backed up, then test deletion/modifications within a sandbox and test multiple scenarios on new record creation and record modification.

  • If the change is large enough, bring in power users to test these processes.

  • Before making these changes in your production environment, communicate to your user base that you are making org updates (ideally out of key business hours and not at the close of a quarter or year-end) just to provide additional cover if your deployment goes sideways.

  • Make ‘hot fixes’ to cover a poor deployment and add to the technical issue you are trying to solve.

Summary An unruly org was not made overnight and it can’t be fixed overnight. Holding yourself accountable to make small incremental progress is a great mindset. This can be as miniscule as learning what a single of Apex does within a class – progress is progress. While portions of this cleanup are grueling, boring, and honestly, relatively thankless, the process will leave you with an incredibly strong understanding of your org and a fantastic foundation to build upon.

Post Source Link

2 views0 comments