Depending upon the size of your Salesforce org or project engagement, an Admin may need to have a general understanding of deployments and the interaction between sandboxes and production environments.
During deployments, issues can happen. If you are unprepared to handle these deployment snags, you could render your production org unusable for a certain amount of time or cause major headaches for your user base. Even if you know nothing about the deployment process (change sets, dependencies, etc.) there are a few ways you can be prepared to triage basic deployment headaches. Read on to discover how you can prevent and recover from deployment issues!
Understand What Is Being Deployed
This is arguably one of the most basic, but one of easiest to overlook aspects of code when you are an Admin. It is incredibly easy as an Admin to say, “I am not a developer, that is not my job to understand code.” Depending on the size of your org and your role, this may be somewhat true. I would argue that while an Admin should not need to be able to write comprehensive triggers or understand the nuances of classes, they should understand in general terms what the code is doing, how to navigate the dev console without trepidation and understand which objects the code is interacting with.
This is especially true if you are working with a third-party developer for ad-hoc pieces of code. Chances are high they will not have the basic business context an Admin would, and therefore will not be a great resource for troubleshooting quick user inquiries. If your budget can allow for this, it is smart to build in time for the developer to walk through the general mechanics of the code along with documentation into your budget to ensure you can broadly articulate this metadata for when, not if, something breaks.
Block Your Calendar
Ideally, any metadata deployments should be done out of hours to reduce user friction, but even then, prepare for and anticipate issues. Depending on how comfortable the Admin feels about the process and how complex the metadata deployment is, block out more time on your calendar. Be ready for and anticipate errors. During this period, section off time to be able to answer user questions and also to conduct testing of your own to ensure functionality. Have coffee or a beverage of choice (no judgement here) and brace yourself for the questions!
Be mindful that deployment inquiries do not end after the first day. Issues can crop up days, week, and yes, even months after the scheduled deployment day on your calendar. In the days following, continue to block certain portions of time and even consider holding some weekly ‘office hours’ for less severe issues that may crop up in the weeks following. Ideally, after the first 5-10 days, you should be out of the critical triaging period and now developing requests for feature improvements or a potential phase 2 rollout.
Schedule Pilots
While you may be testing on your own, it can be useful to schedule a pilot with power users and block time with them to test thoroughly. Ideally, these tests should be done in a test environment but you should also consider a run through in production to ensure functionality is as expected (because if everything worked fine in production as it did in test, then there would be no point in this article).
Leverage permission sets as a potential solution to test this functionality; in this way you can grant just your power users access to new features for testing in production.
Additionally, leverage some checklists to have your users run through basic procedures, user journeys and tests. Even a basic spreadsheet can work for this process. This pilot can add additional confidence and simultaneously facilitate distributed knowledge, as well as establish ‘champions’ depending on the process changes taking place.
Be Prepared to Rollback
Depending on the complexity of what you are pushing into production, you may need to rollback these changes if there are major oversights. Communicate this possibility to your development partner (if you have one) and ensure there is a plan in place to roll this code back and out of production. Additionally, if you are not already doing so, be sure to start generating weekly backups in case any of these changes will impact your existing data set. Get comfortable using data loader tools to restore data and be ready to use these skills if anything goes wrong.
Communicate
Whether it’s an email or a conversation at a meeting, it is always wise to let your user base know that changes are happening. This should be done even if this code is being pushed outside of normal working hours. Provide some buffer for issues and plan to send a communication once the period is over and any initial testing is completed. In these types of situations, overcommunication will save you the chance of user confusion and multiple messages help to ensure your intent is not overlooked.
Like any org, there is a spectrum of sophistication in your user base; certain individuals appreciate the technical nuances of the changes while others just want high level details. Trying to craft a harmonious message to satisfy all of these audiences is equivalent to crafting a menu for a large family reunion, no matter how many hours you devote to the plan someone will inevitably complain. What I have done in the past is list the high-level details up top and then made an aggressively clear demarcation and heading to denote the dreaded ‘technical details’ and their contents. This allows users to understand what is happening and provides them with the related business context so they feel involved, while the power users can view the details to their heart’s content.
The decision on the type of training materials can be equally as arduous as the communication style decided above. While it is more leg work, I have found success in multiple formats: documentation, live training you can ideally record and then a video demo of the navigation. If you are going to speak, invest in a good headset and do your best to speak slowly and clearly. This may seem obvious but if you have spent weeks, or even months, building the configuration, you may glaze over details because you are so intimately aware of the nuances. Once you can ensure all of these materials are quality, try not to bend to every request for various formats. The reason this is important is that you are setting yourself up for an operational nightmare if you have to navigate to 10+ platforms to update these materials.
Summary
Deployment processes can cause a great deal of fear and a major perceived loss of agency for admins. Having even some basic understanding of these tenants can alleviate the unknown factor that is common during these processes.