Posted
Feb 18, 2016 08:50 AM
Want to experiment with new ideas in Salesforce but don't want to ruin your existing database? "Sandboxes" are test spaces where you can try out new things like objects, fields, workflow processes, and page layouts without making a single change to your current configuration. Not all sandboxes are the same, to it's important to learn the differences before setting up a new one.
You may have heard the term “sandbox” used from time to time while using Salesforce. A sandbox is simply a copy of your database you can use to test new ideas.
Oftentimes, when you work with a consultant on new functionality for your database they will build and demonstrate it for you in a sandbox before it becomes part of your actual database. However, there are different types of sandboxes and not all of them are the same.
As part of your Power of Us Enterprise Edition of Salesforce you get for free six Developer sandboxes and one Developer Pro sandbox. The only difference between the two is that the Pro sandbox holds more data. Otherwise they are the same and the standard Developer sandbox is usually all you need.
There are also Full and Partial sandboxes which not only include your database configuration but also some or all of the actual data.
To summarize, all sandboxes include a full copy of your code and configuration but not necessarily your data. Here’s a quick comparison of all the types:
- Developer - Does not copy your records but can store up to 200 MB of test records.
- Developer Pro - Does not copy your records, but can store up to 1 GB of test records.
- Partial - Includes a sampling of your actual data.
- Full - Includes all of your actual data.
Partial and Full sandboxes are a premium service and are not included for free. Contact your Account Executive for pricing on Partial and Full sandboxes.
You can read more about the differences between the various types of sandboxes.
You can read more about the differences between the various types of sandboxes.
Which Sandbox Should I Use?
A Developer sandbox is a copy of your production database’s configuration only, not the records. So they include all your objects, fields, user accounts, workflow processes, page layouts, and so on, but no data at all. The idea is that you can use these to test new ideas against the current state of your database but you won’t need to use any of your real records. Developer sandboxes are just a configured environment that’s set up the same way as your real database so that you can play around with it.
If you want to be able to test a new configuration AND have real data in there, you have to manually add it or purchase a paid sandbox (Full or Partial). You need to decide if all you need is a handful of records (which you could easily add yourself) or ALL the records in your live database.
In general, unless you have a specific or special need for having all your actual data in a sandbox, you can just use the Developer sandbox for all your testing.
How Do I Set up a Sandbox?
Sandboxes are very easy to create, although you need to be a system administrator to do so. Simply navigate to Setup and type “sandbox” in the quick search box at the top left of the screen. Click on the word “Sandboxes” and you can now view what sandboxes you already have, choose to refresh them, or create a new one. Look for the “New Sandbox” button to create a new sandbox. Just give it a short name and choose “Developer” and you’re all set. It can take a couple of hours for the process to finish but you should get an e-mail telling you when it’s ready.
To login to the sandbox, you can use the Login link right next to the sandbox name or go here.
Now login like you normally would except you must now include the name of your sandbox at the end of your username like this: sam@501commons.org.newdev
Your password will be the same.
To login to the sandbox, you can use the Login link right next to the sandbox name or go here.
Now login like you normally would except you must now include the name of your sandbox at the end of your username like this: sam@501commons.org.newdev
Your password will be the same.
Keeping Your Sandbox Fresh
It’s important to understand how Sandboxes are refreshed or kept in sync with your production database. Once you generate a sandbox you get a copy of all the configuration as it stands on the day you created the sandbox. As time goes on, your production database might have things added to it that aren’t in the sandbox. Changes to your production database do not automatically propagate to your sandboxes! You can refresh a sandbox, but understand that when you do this you are erasing and replacing whatever was in the old sandbox. This means that if you refresh a sandbox that has sample records in it (or something else you wanted to keep), they would be erased and you’d have to re-add them.
In order to refresh a sandbox, go to “Setup,” search for Sandboxes, find the name of your sandbox, and click the Refresh link next to it. Once you initiate a “Refresh” it can take several minutes or even several hours to complete. After the refresh is complete you must then “Active” the sandbox which can also take several minutes.
Remember, when you refresh a sandbox you are erasing and replacing whatever was in that sandbox with whatever is in your production database at the time!
Read this article for more information and considerations on setting up and refreshing sandboxes.
In order to refresh a sandbox, go to “Setup,” search for Sandboxes, find the name of your sandbox, and click the Refresh link next to it. Once you initiate a “Refresh” it can take several minutes or even several hours to complete. After the refresh is complete you must then “Active” the sandbox which can also take several minutes.
Remember, when you refresh a sandbox you are erasing and replacing whatever was in that sandbox with whatever is in your production database at the time!
Read this article for more information and considerations on setting up and refreshing sandboxes.
Moving Changes from a Sandbox to Production
At times you want a sandbox simply to be a place to experiment and learn about the features of Salesforce without imperiling your actual database. But sometimes you’re working in a sandbox in order to create new functionality like new objects or a new workflow. If you’ve only made a few changes it’s easy enough to move over to your production instance and just go through the steps of re-creating your new items. However, what if you have a lot of changes that you’d like to move over all at once? The answer is Change Sets!
A Change Set is a package of new items like fields, objects, Apex code, Visualforce pages, and other things. You can have as few or as many items in a Change Set as you might need. In the Sandbox you would create what’s called an Outbound Change Set into which you put all your new configuration. You then upload your Change Set to the production instance and then from there you deploy the changes as an Inbound Change Set.
There are a few steps you need to go through first, including creating the initial connection between your sandbox and your production instance. However, once you have things figured out, it’s quite easy to move configuration in bulk from the sandbox.
Typical Salesforce development cycle:
For more information on Change Sets, refer to this article.
A Change Set is a package of new items like fields, objects, Apex code, Visualforce pages, and other things. You can have as few or as many items in a Change Set as you might need. In the Sandbox you would create what’s called an Outbound Change Set into which you put all your new configuration. You then upload your Change Set to the production instance and then from there you deploy the changes as an Inbound Change Set.
There are a few steps you need to go through first, including creating the initial connection between your sandbox and your production instance. However, once you have things figured out, it’s quite easy to move configuration in bulk from the sandbox.
Typical Salesforce development cycle:
For more information on Change Sets, refer to this article.