Let’s talk about Sandboxes

Sandbox-for-blogI have recently been working on my Salesforce advanced administrator certification, and one of the sections is on change management. An important part of your salesforce change management strategy has to include the use of Sandboxes. Unless you are working with a very small org with nearly no customizations, trying to implement automation or solutions in your live environment is just asking for headaches. Sure you can create reports and dashboards or add items to picklists in the live org, but make one mistake in Process Builder or on a workflow and you can cause your business to grind to a halt! 

A sandbox lets you develop and test your processes in the safety of a controlled environment that is not going to impact your actual day to day operations. Once you know that your new workflow or automation will correctly interact with existing programming you can go ahead and promote to your live org.
Sandboxes come in a few different varieties, you can see the different names in this image:


What are each of these sandboxes and when should you use each one? Below I will explain each type and then give some examples of use cases for them.


These sandboxes are meant to be used for testing and/or coding in an isolated environment. This sandbox includes your production org’s meta data, can be refreshed every 29 days and whose storage limit is based on your productions.

Developer Pro

Like the Developer sandbox the Dev Pro environment is meant to be used for testing and coding and include your prod org’s metadata. Where these sandboxes differ is that the Pro has a larger storage limit. This just gives you more space to test larger more robust data sets, as well as run more quality assurance tasks. The Developer Pro sandbox can be refreshed once a day.

Partial Data Copy

In addition to containing your meta data, these sandboxes contain a subset of your production data. The data subset is defined in the sandbox template. Use this if you want to do coding or testing on the data from your org. You can refresh a partial data copy every 5 days.


The full sandbox is basically a copy of your production organization, all data including attachments, object records as well as the meta data will be included. The difference being that the data in your full sandbox is not a “live” copy. There is a refresh limit to how often you can update the data in the sandbox. This sandbox is meant to be used for testing, once your development or coding is done in a dev or dev pro sandbox. This let’s you see how your new process or workflow etc, reacts to the data. Finally when you are creating your full sandbox you have the option of how much field tracking and Chatter activity you want to include. By default field tracking will be set to off, but you can enable it and capture upto 180 days of history. Bare in mind that depending on how extensively your company uses Chatter, the feed data can be overwhelming. You may not want the Chatter feed in your testing area.

Further Information

Finally here are some Sandbox details and limitations from help.salesforce.com:

The following limits apply to sandboxes.

  • You can refresh a Full sandbox 29 days after you created or last refreshed it. If you delete a Full sandbox within those 29 days, you need to wait until after the 29 day period, from the date of last refresh or creation, to replace it.
  • You can refresh a Partial Copy sandbox 5 days after you created or last refreshed it. If you delete a Partial Copy sandbox within those 5 days, you need to wait until after the 5 day period, from the date of last refresh or creation, to replace it.
  • You can refresh a Developer or Developer Pro sandbox once per day.
  • Enterprise Edition includes a license for 1 Developer sandbox.
  • Performance Edition includes licenses for 1 Full sandbox, 1 Partial Copy sandbox, 5 Developer Pro sandboxes, and 30Developer sandboxes.
  • Unlimited Edition includes licenses for 1 Full sandbox, 5 Developer Pro sandboxes, and 15 Developer sandboxes.
  • If you need licenses for more sandboxes, contact salesforce.com to order sandboxes for your organization.

The following limits apply to Sandbox storage limits.

  • Partial Copy sandboxes have a 5 GB of files and a 5 GB of data storage limit.
  • Developer Pro sandboxes have a 1 GB of files and a 1 GB of data storage limit.
  • Developer sandboxes have a 200 MB of files and a 200 MB of data storage limit.
  • Full sandboxes have the same storage limit as your production organization.
  • Sandboxes don’t send email notifications when storage limits are reached. However, if you reach the storage limit of yoursandbox, you can’t save new data in your sandbox. To check your storage limits, from Setup, click Data Management | Storage Usage in your sandbox.


In wood shop at school we were taught to “measure twice and cut once”, we can follow the same though process by using sandboxes for development and testing before promoting to our Production orgs. Get in your sandbox and play around, explore and have fun! But keep your production data safe.


Subscribe To The Monthly Newsletter

No Spam. No Rubbish. Just great content from the Salesforce Industry.

You have Successfully Subscribed!

3 thoughts on “Let’s talk about Sandboxes

  1. Salesforce Sandboxes are really great as it only takes a couple of clicks to create a copy of your production environment. But the one thing a little annoying is with the partial sandboxes. They only copy the first 50k records of an object. So if you have a large org you usually end up with the oldest and usually most incompleate records in your org. It would be much better if you got the latest 50k records instead or have a choice.

  2. This is a great topic – thanks for posting this and giving some good insights into the possibilities. We see Salesforce customers doing all kinds of odd things to provision sandboxes and the like, but it is good to see the choices!

Add Comment