Let's be Real about Salesforce Sandboxes
Sandboxes. You may have pleasant childhood memories, as I do, of playing in one like the turtle pictured with this blog post. You may also, as a Salesforce Administrator, have uncomfortable adulthood memories of times when you built something directly in Production and suffered the consequences. Or you may not… yet. You may know in your heart that making configuration changes in a live (as in currently-in-use) Salesforce org without a solid Sandbox strategy is going to hurt in the long run, but what does this really mean for you? Perhaps you have a small team, or are under pressure to make changes fast, or you struggle with the deployment process — so let’s be real about Sandboxes and when and how it’s important to use them, by discussing a few key scenarios.
“What is a Sandbox strategy anyway?”
Another blog post. Or five. If you do not have a Sandbox strategy for your Salesforce org, I suggest getting on that ASAP and ensuring all system admins and any partners you are working with are all on board. It can be as simple (here is the one Sandbox where we do stuff before it goes into Production) or as complex (series of Development and QA Sandboxes, release cycle and all) as your organization needs; the important part is that you have one and stick to it. I highly recommend this Trailhead Module on Change Management to fully understand Sandboxes and how to apply a Sandbox and Deployment strategy to your own organization.
“This really doesn’t need ‘testing’ per se.”
This one’s for the whiz kids out there. You are super confident in the change you are going to make, and no one else needs to review it. Awesome. Me too. I literally configure Salesforce all day, often similar things for many different clients, and they just want it done, fast and no fuss. But on a regular basis, I go to make a change, and in the process of going through all the tangentially affected items (got to add that field to that custom report type!), I stumble across something I need to double-check or reconsider. I don’t care how well you know Salesforce and/or your own org; you are not immune to this. Taking the time to go through all the considerations prior to making a configuration change is a great practice, and doing this hands-on, in a Sandbox, is an important part of that.
Even in situations where there are very few users and/or very small changes, it’s always good to make sure changes are rolled out in a clean fashion. So even if you don’t technically need to ‘test’ a change, the process of doing it in an environment where no live data or users are affected, before doing it in one where they are, saves you from a number of uncomfortable scenarios, such as reconsidering a change or having it reflected properly in one layout, etc. but not another and confusing someone or causing inconsistent data. It only takes an instant to make a mess. Take the extra few minutes to do it right.
“Just this tiny change won’t matter, right?”
Maybe. I guess. On rare occasions. But then you have something in Production that is not reflected in the Sandbox, and you may not be able to refresh right away because of limits or other pending configurations or user needs. Then the only responsible thing to do is to actually deploy that change into your Sandbox (yes, it can go both ways). So you’ve ended up taking the same amount of time, configuring and deploying, as you would if you had done it in the Sandbox first. If you skip this step entirely, you end up losing even more time later. This comes in two forms, and I can tell you these situations come up All The Time.
The first form is what I like to call Missing Field Scope Creep, though the same concept applies to any number of inconsistencies. You’re going along trying to configure something and oops! that field just isn’t there. Now what else is different? Now I need to go look… and so the clock winds on. Or worse I don’t even know that field is missing, and after deploying that new Process, I have to go back and fix it because it’s leaving out a key field that should be copied onto that other record and tick, tick, tick.
The second form is when something that you should be able to just deploy cannot actually be deployed because it will overwrite changes made in Production. This happens often with Page Layouts, and boy do I love sitting with the page layouts side by side in Production and Sandbox, making sure I get everything right, don’t you? Wouldn’t it have been so much easier just to add it to the change set? Exactly.
“Change sets are a pain in the you-know what.”
In some ways, yes. And there are a lot of Ideas out there on how to improve them, so go vote or submit your own and then we can talk, ok? In other ways, consider how amazing this tool is, that runs tests for you and everything. Moment of gratitude. Ok, done; now moment of Real. It may take time to assemble, upload, validate, and deploy, but that time is worth it, and it’s really not that hard. If you are not familiar or particularly comfortable with change sets, the Trailhead module I linked to above really spells it out quite well.
Change sets have limitations, and it’s important to understand how change sets work and what can and cannot be deployed using change sets. For more advanced users, there are also other options for migrating changes such as the Force.com Migration tool, and these tools have their own sets of considerations and limitations. Just because you can’t deploy something exactly, though, is not a good reason not to do it in the Sandbox first; in fact I think it’s even more important since you don’t get that double-check. Yes, sometimes you really do have to do it twice, and that’s okay; you are doing it right.
Want to share a horror story from skipping the Sandbox step? Or a tip for good configuration stewardship? Feel free to comment below, on the Salesforce Success Community, on our Facebook page, or directly at me on Twitter @ifitfloats.
