If you have kids you’ll know how disgusting a sandbox can get. Just keep that in mind as you read this post and think about how it applies to some of the things you’ve done in a Salesforce sandbox over the years.
One thing I’m really growing tired of is dealing with half-baked tests, proof of concept examples, and random fields with no descriptions in the sandbox that I’m using to deploy changes to Production. Part of the reason for this is that prior to the Spring ’16 release Enterprise Edition orgs only got a single sandbox. So if an admin is trying something new, they only have one sandbox to work in. As of the Spring ’16 release you now get 25 with the same edition. This post is going to talk you through how to leverage one or more of those 25 to stop screwing up the sandbox you need to make real deployments from, and separate your playground from your deployments.
In one of my first posts I said that one of the amazing things about a free developer edition is that nobody can see you screw up, and that’s a big reason why I’m such an advocate of them. Nobody needs to know how and when you are learning new things, at least until you get it working and can claim you got it on the first try. Now that every Enterprise Edition org has 25 sandboxes, it’s time as an Admin to start using one as your own personal playground. What I mean by this is one of the first things you should do is create at least two sandboxes
- The first one is what you will use to make actual changes. This is so you don’t make them directly in Production. I really hope I don’t need to explain that one
- The second one is what you are going to use to
- Mess around
- Make mistakes
- Create fields really quickly because an end user just can’t imagine what a new field will look like without you showing them a screenshot with that new field in it, so you create a new field on the fly, just so that you can add it to the page layout, so that you can get back to work. I guarantee you didn’t fill in the description or help tip while they were sitting there watching you create it. If they decide they don’t want it, you probably also forgot to delete it.
- Try something in Process Builder or Flow that you have no idea if it will work or not, but you think it might. You may or may not give up on it
- Turn off validation rules so that you can mess around with test data and create records faster
- Add fields without worrying about where they go in the page layout
- Generally just half-assing anything you are trying to do, because at this point it doesn’t matter, and you can touch it up later
The problem up to this point has really been the last part there. People do things quickly in a sandbox and forget to do them properly later on, because they are trying to turn something around very quickly. What you are left with is a really annoying version of chaos, that in the end costs you time.
So let’s talk about how to set one of these up. There are a few things I like to do to make sure that there is zero, and I mean zero confusion as to what this sandbox is being used for. The goal of this new sandbox is not to have anything work long term, it’s just for short spurts of activity that you can walk away from and not feel bad about because you’ve removed the negative repercussions. My feeling is that if after a few months this playground sandbox isn’t completely unusable – you are either really really good at everything, you never have to prototype anything, or you aren’t trying enough things out on your own.
1 – Create a new app
I’m not going to explain how, it’s all here. What I will say is make it the default for your new sandbox, and take the time to create a custom logo that really makes it pop. Something like this:
2 – Create an HTML warning on the page
This part only seems intimidating, but it’s really easy. Go to Setup > Customize > Home > Home Page Components and click the New button for a new custom component. Follow the basic steps to make it an HTML area component, and then add and format your test. Unlike HTML email templates, you don’t actually need to know HTML to create this
Next up just add it to your homepage layout right at the top.
The best part about doing it this way obviously is that you can be subtle like what you see above. Nobody should ever be confused as to what this sandbox is being used for, or why something isn’t working. You can even let end users into this sandbox with extra permissions (to change a page layout for example) without any fear that they’ll mess something up on you – because you really don’t care what they do since it won’t matter.
Note: These simple HTML areas are also a great way to warn your users of upcoming deployment windows where they will be locked out of the system while you make changes. Hopefully by
3 – Do whatever the heck you want in there
This is the best part. Now you can
- Create all the fields you want
- Change anything, and I mean anything
- Lock everybody else out if you want to do stuff in private
- Let everybody else in if they also want to play around
- Not have to constantly remember to delete fields / rules / automation in your real sandbox that you’ve decided not to proceed with
4 – Only change your real sandbox when you know you are moving it to production.
This is the big one. Now that you’ve done your proof of concept or general testing, you can sit down, take your time, and do things right in your real deployment sandbox. This means
- Descriptions on every field, process, rule that you create
- Do your testing and only have to worry about what you are going to deploy
- Document as you go
- You’ll have a nice clean deployment (hopefully)
The hardest part is avoid the temptation to deploy your changes from your playground to your other sandbox. Copy and paste some things if you want, but for any of the point-and-click stuff you’ve done, do it again by hand. This is your chance to make sure you’ve done it right. In 6 months time when you go back in, you’ll be really glad that you took the extra few minutes populating those field and rule descriptions.
If the whole sandbox and deployment strategy is still new to you – head over to Trailhead and read through their guide on getting started. It’s a great resource if you are just starting to think about what strategies to implement at your own company
This is so easy to setup yet not enough people seem to do it. Two months later you go to deploy and you can’t remember what you changed in an approval process, or you forgot about that validation rule you turned off, or it’s entirely possible you messed something up and just didn’t catch it in testing. Setting up a 2nd sandbox with a new app and logo is probably 5 minutes of actual work. You’ll get that back the first time you don’t have to delete the custom fields you created and don’t actually need anymore.
To me, messing around in the sandbox you are deploying from is just a terrible practice. Granted, prior to Spring ’16 if you needed all your current customizations in there to build against you didn’t have much of a choice, but now, if you can’t spare 1 of 25 sandboxes for a playground, then it’s your own fault the next time you lose a Friday night to a bad deployment. The trick with something like this is to make sure everyone is on the same page. I put in the logo and warning so that I don’t have to take a phone call from anybody asking me why a page looks different, why there is a new field, or why all the Leads and Contacts are actors from Top Gun.