In short, a sandbox is a copy of your Production instance, which is the Salesforce instance that your users log into and use each day.

By creating a copy of your Production, with all the unique configurations and use cases that your organisation has, you create a safe place to test out new things without worrying about breaking your live system or messing up your live data.

First, let’s talk about the different things you might want to do outside of a live system:

1. Building new functionality – Any time you build new functionality, you run the risk of breaking existing functionality in the process. This could something as simple as making a field mandatory or something as complex as adding an event management function to your system. Building and testing new functionality in a sandbox means that you can make changes out of sight of people using your live system and you can make sure you find any issues before you move your changes to Production.
2. Training – Sometimes you want your users to practice a little without ending up with a database full of Mickey Mouse’s and Brad Pitt’s. Letting users log into a sandbox gives them all the same rules and access as they have in Production and lets them stretch their wings a little without risking your data integrity.
3. Controlling access to live data – If you have especially sensitive data in your Production instance, maybe you’re working with patient health data for example, but you need a Salesforce partner or other third party to review your configuration, you can always create a sandbox without any of your live data so that a third party can see how everything is set up without breaking any privacy commercial in confidence considerations.
4. Environment management – For larger organisations with lots of ongoing and overlapping development, creating multiple sandboxes with different functions is important to reducing project risk. Initial development and unit testing can be done in a segregated sandbox, and the configuration can be moved to another sandbox for integration and user acceptance testing. Finally, once everyone is confident that the new functionality is fully tested and ready to go, it can be deployed to your Production for go-live. Salesforce has specific tools built in to help you move configuration from one sandbox to another and from a sandbox to Production.
5. Playing and experimenting! – This isn’t an exhaustive list of ways to use a sandbox, and you’re really limited by your imagination. You can think of them as safe places to try something out, no matter how crazy. If you like the look of something you see in the Salesforce Appexchange, spin up a new sandbox and install the app into your sandbox to try it out. If you’ve read online about some fancy new process builder or flow that some super admin built, try building it yourself in a sandbox. There’s no risk to your live system, and it’s a great way to keep learning about Salesforce. This is why they’re called sandboxes!

Every Salesforce customer has access to sandboxes, although the number and type of sandboxes you have access to is dependent on the edition of Salesforce you’ve purchased (see link here) If you’re not sure which edition you have, it’s probably Enterprise Edition, although you can always check with your Salesforce Account Executive).

Although the different types of sandbox are better for different things, all of the above functions are possible in all the sandbox types. Happy sandboxing!