It's fun (and essential) to play in the sandbox

I sat for, and passed, the Development Lifecycle and Deployment Designer certification earlier this month and it really was a reminder of the importance of sandboxes for all Salesforce admins and developers. This exam, being part of the architect track, is pitched at a more technical level than that of your average admin, but proper use of sandboxes does not require this kind of experience and is definitely not just for developers.

Last year I wrote a series of posts entitled Best Practices and Recommendations for New Admins and one of the Tools from post four was Sandboxes. Here is a deeper dive into the world of Salesforce Sandboxes.

I was shocked recently to hear a tale of an end customer having no sandboxes in use at all. There really is no excuse, sandboxes are available to all customers. How many, and what type, depends on your edition. Here is a handy grid to tell you how many you have access to out of the box. You can, of course, buy more.

Why make it complicated and have four different types of Sandbox I hear you ask. The grid below should help, the key difference is the available storage in each type, and what data is copied over from your Production org upon creation.
The most desirable sandbox is the Full sandbox as it replicates your Production instance exactly. This is where you can test new functionality in a like for like environment.

You may also ask, why should I use a sandbox and add to my workload, slowing me down?
You may tell me that you did all your development before your instance went live but I challenge this and propose that the four main scenarios below mean that a sandbox still has a place in your world, even if you are not releasing many new features.

Training Users
You don't want to litter your production instance with test data, skewing your pipeline and leading your users to believe that data quality is not important (it always is).

Troubleshooting and Testing
A user reports an error or unexpected behaviour in your org, you need to attempt to replicate the issue but without impacting your production instance.

Enhancements
You may feel that you have gone live with all the functionality you will ever need but this cannot be the case. Requirements and business use cases change all the time. If they are not then the business has other questions to answer. If you are using any of the declarative tools available such as Process Builder, Flow, Workflow Rules, Validation Rules to enhance your user experience or cater for a new requirement then you must do this first in the Sandbox.

Loading Data 
Always complete a dummy run in a sandbox to make sure you don't overwrite data, trigger processes unknowingly, or miss key fields.

Next you will probably ask, what's the difference between a sandbox and a developer edition, or even a scratch org.
Oh yes, it can be confusing, particularly since there 3 environments have the word developer in their name.
Sandboxes (full, partial, developer, or developer pro), are taken from your production environment and so share its structure and set up, so you will see your custom objects and fields, as well as your users.
Developer editions (also Trailhead Playgrounds and Admin Playgrounds) are stand alone production environments which are pre-populated with the standard Salesforce objects, access to the majority of features and clouds, and also include dummy data.
Scratch orgs are produced off of a production org, which could be a developer edition, but are more temporary, as they are meant to be produced and used on a project by project basis. The default lifespan is only 7 days. You can find more information about scratch orgs here.

If you weren't already convinced of the importance of a sandbox in your development and deployment plans, then I trust you are now.

Go on, give it a try, feel the sand between your toes!