Set Up a Sandbox in Your Salesforce Org

Learning Objectives

After completing this unit, you’ll be able to:

Understand the different types of sandbox orgs.
Set up a sandbox in your own Salesforce org.

What is a Sandbox?

Two NPSP admins build sandcastles in a sandbox.

A Salesforce sandbox is a place for you to test and build without risk of changing or losing the valuable data in your main, or production, Salesforce org. Sandboxes are the perfect tool for keeping your data clean during training, testing, and development.

No matter the size of your organization and no matter what feature you’re changing or adding, it’s always a good idea to first test these features in a sandbox.

There are four types of sandboxes, each suited for different tasks.

Type of Sandbox	What’s Included	Recommended Uses
Developer	All of your production org configurations (including custom objects, fields, etc.), but no production data. Can be refreshed—or pull in the latest configurations from production—once a day.	Good for development and testing. Because it includes all of your configurations, you can develop with the custom fields, objects, and other settings that exist in your production org, but it doesn’t include any of your real-world data.
Developer Pro	All of your production org configurations, but no production data. Can hold more data than a Developer sandbox. Can be refreshed once a day.	Good for development and quality assurance tasks, testing, and user training. Better than a Developer sandbox if you’d like to use more sample data in these processes.
Partial Copy	All of your production org configurations, plus a sample of your real-world data that you define using a sandbox template. Can be refreshed once every five days.	Good for user acceptance testing, integration testing, and training, because it contains some of your production data. Seems more like your production org than a Developer or Developer Pro sandbox.
Full	A full replica of your production org, including all configurations and all or most of the data. Can be refreshed once every 29 days.	An ideal testing environment since it is just like production. This is the only type of sandbox that supports performance testing, load testing, and staging. You probably don’t want to use Full sandboxes for development, though, because you can only refresh configurations and data every 29 days, and that refresh can take days to complete.

The type and quantity of sandboxes you can set up and use depends on your license. If your organization uses the 10 donated licenses through the Power of Us program, you usually have an Enterprise Edition license. This means you can set up at least 25 Developer sandboxes and one Partial Copy sandbox—not a Full sandbox, which will have to be purchased through your Salesforce Account Executive. Check out the Sandbox Licenses and Storage Limits by Type link in Resources and talk to your Salesforce account executive if you need more or different sandbox options.

Here’s an example of different sandboxes in action: Gorav Patel, the Salesforce Admin at the (fictional) nonprofit No More Homelessness (NMH), uses Developer sandboxes when he is adding new fields, objects, and apps to test them quickly. For releases, as we mentioned in the last unit, he uses his Partial Copy to see how new features interact with a sample of NMH’s existing data.

Now that you understand the different types of sandboxes, let’s learn how to set one up.

Create a New Sandbox

Let’s start by setting up a Developer sandbox. Note that you have to do these steps in your Salesforce production environment—you can't set up a sandbox in a Trailhead Playground or another Developer Edition org.

Go to Setup by clicking the gear icon () in the navigation bar and then Setup.
From Setup, enter Sandboxes in the Quick Find box, then select Sandboxes. You can see how many available sandbox licenses you have at the top of the page.
Click New Sandbox.
Enter a name and description for the sandbox. We recommend a name that describes how you’ll use the sandbox and has only a few characters, like QA, Release, or AppTesting.
You can also select if you want to create your sandbox from production or another existing sandbox. You’ll usually select production unless you’d like to copy the configurations from another sandbox, which may be helpful if you’re developing an app and want to bring in objects you created there.
Select the type of sandbox you want to create and click Next. We’ll select Developer here, but if you select a Partial Copy or Full sandbox, you will also have to select a sandbox template to specify what data you would like to use to populate your sandbox. (Check out Create or Edit Sandbox Templates in Resources for details.)

If you don’t see a sandbox option or need licenses for more sandboxes, contact your Salesforce Account Executive to order sandboxes for your org.
On the next screen, you can optionally specify a script to run after each creation or refresh for the new sandbox by entering an Apex Class. We won’t add one in this example.
Click Create.

Your sandbox won’t be ready right away. It could take several minutes to several days, depending on how much data you are copying and your type of org. You’ll receive a notification email once your sandbox is ready.

You can access your sandbox by going to https://test.salesforce.com. To log in, use your password from the day the sandbox was created and add a period and your sandbox name to the end of your normal username, such as gorav@nomorehomelessness.org.AppTesting.

Important Sandbox Settings and Notes

Once your sandbox is set up, there are a few things you’ll want to check.

First, make sure you’re in your sandbox when you start to work! It will look like your production org except for the ribbon along the top of the browser window—above the navigation bar—letting you know which sandbox you are using.

A Sandbox ribbon along the top of the browser window

When first logging in to a new sandbox, check the email deliverability settings. Yes, some sandboxes can be set to generate emails—even to your donors and other stakeholders outside of your organization!

Go to Setup by clicking the gear icon () in the navigation bar and then Setup.
Enter Deliverability in the Quick Find box, then select Deliverability.
Make sure that Access level is set to System email only (which only allows automatically generated emails like new user and password reset emails) or No access (which prevents all emails).
If you want to change the Access level, make your selection and click Save.

Note

System email only is the default deliverability access level on any new Sandbox, so make sure that the setting is correct on older sandboxes if you are new to your organization.

Next, check your NPSP configurations in the NPSP Settings app in your sandbox, especially if you're using a Developer or Developer Pro sandbox. Some of the settings in NPSP are stored as data and not configurations, so you may not have everything you need. For example, if you use a default General Accounting Unit (GAU), the setting that enables a default GAU will be created in the sandbox, but the GAU record itself (which is classified as data) won't exist in your Developer or Developer Pro sandbox. You'll have to create that GAU record or change your default allocation in NPSP Settings to work with opportunities.

Another important consideration about sandboxes concerns their creation and refresh.

You can think of a sandbox as a snapshot in time of your production org. It’s kind of like a single frame from a movie—while the movie keeps going, you’re pulling out a single image to work from. When you create a new sandbox, it copies all of the configurations and data you specify at that moment, but it doesn’t keep up with changes until you capture another single moment.

A sandbox org is like a single frame selected from an ongoing movie

To add new configurations and data from production to your sandbox, you need to refresh that sandbox by going to the Sandboxes list in Setup and clicking Refresh next to the sandbox’s name.

But hold up! A refresh will give you a new snapshot of your production org, but it also destroys any of the data or customizations you created in your sandbox since your last refresh. Make sure you don’t overwrite work you were hoping to move to production when refreshing!

Plus, remember to check email deliverability and NPSP settings again with every refresh, because anything you changed since you created or last refreshed your sandbox will be destroyed.

Next, let’s check out three ways to use your sandbox: for training, to test releases, and to make and deploy changes to production.