Learning Objectives

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

  • Choose the appropriate sandbox for different scenarios.
  • Know when to use sandbox templates and when to import data.
  • Manage users and licenses in sandbox.


Sandboxes create copies of your Salesforce org in separate environments. Use them for development, testing, and training, without compromising the data and applications in your production org. Sandboxes are isolated from your production org, so operations that you perform in your sandboxes don’t affect your production org, and conversely.



Where’s my sandbox? Your Trailhead Developer Edition org doesn’t contain a sandbox because sandboxes aren’t available in Developer Edition orgs. Sandboxes are available in some editions, including Professional, Enterprise, and Unlimited. The following sections help you understand sandboxes so that you can learn how to use them in a supported edition.

Types of Sandboxes

There are four kinds of sandboxes.
Developer sandboxes copy only the org’s configuration, no data. You can create or load up to 200 MB of data, which is enough for many development and testing tasks. You can refresh a Developer sandbox once per day.
Developer Pro
A Developer Pro sandbox can store up to 1 GB of data (about 500,000 records). It’s otherwise similar to a Developer sandbox.
Partial Copy
A Partial Copy is a Developer sandbox, plus a sampling of data that you define in a sandbox template. You have limited control over the data that is copied. You can choose the objects, but not the records to pull. The sandbox can include up to 5 GB of data, which is about 2.5 million records, with a maximum of 10,000 records per object. You can refresh a Partial Copy sandbox every five days.
A copy of your production organization and all its data. Because the Full sandbox is an exact copy, the amount of data in the sandbox is the same as your production org. You can refresh a Full sandbox every 29 days.

Refreshing Sandboxes

Refresh your sandbox periodically to update it with data and metadata components from production. Refreshing sandboxes ensures that your sandbox doesn’t miss any changes that were deployed to production by another sandbox or manually introduced in production. When you refresh a sandbox, Salesforce rebuilds your environment and erases its old contents. The content in your new sandbox is replaced with a copy of the production org. Beware that it’s possible to overwrite all the development you’ve done in your sandbox. Therefore, it’s a good practice for each developer to have their own sandbox and make their own backups. Establish a process with the rest of the team for refreshing sandboxes.

How often you can refresh your sandbox depends on the sandbox type. The following table lists the refresh cycle per sandbox type, along with some other statistics.
Table 1. Sandbox Comparison
Developer Developer Pro Partial Copy Full
Refresh Interval 1 day 1 day 5 days 29 days
Copies Data No No Yes Yes
Size 200 MB 1 GB 5 GB Same as production
Templates and Sampling No & No No & No Yes & Yes Yes & No
Bundled Developer Sandboxes N/A 5 10 15

Sandbox Uses

Full sandboxes are required only for performance and scalability testing, as well as for staging before final deployment. You might also need a Full sandbox to test triggers that make non-selective queries. For all other use cases, a partial copy of data is enough. For testing, it’s often better not to copy data at all, but rather load the same set of data every time. Data is time consuming to copy, and a large volume of data can take days to complete.

The following table compares sandboxes and their ideal use.
Table 2. Sandbox Uses
Use Case Developer Developer Pro Partial Copy Full
Develop Check mark indicating true Check mark indicating true Check mark indicating true
QA Check mark indicating true Check mark indicating true Check mark indicating true
Integration Test Check mark indicating true Check mark indicating true
Batch Data Test Check mark indicating true Check mark indicating true
Training Check mark indicating true Check mark indicating true
UAT Check mark indicating true Check mark indicating true
Performance and Load Testing Check mark indicating true
Staging Check mark indicating true


Creating or refreshing a sandbox doesn’t happen via the Metadata API, so the components copied aren’t restricted to objects that have XML representations. Therefore, you get a true and complete copy of everything in the production org. After initial creation, you can refresh the sandbox, creating a new sandbox in place of the old one.

Using Data in Sandbox

You can supply data for testing in sandbox in several ways.
  • Use sandbox templates to provide real-world data that makes your testing environment more closely resemble your production instance. Sandbox templates are available only in a Partial Copy or Full sandbox.
  • Import external data into your sandbox to make repeatable testing easier because the data set is static and can be relied on not to change.

Copying Production Data with Sandbox Templates

If you have a Partial Copy or Full sandbox, you can pick which standard and custom objects to copy over from production by using sandbox templates. Sandbox templates help you limit the size of your sandbox by limiting the data that is copied over. Generally, you need only a representative set of data for testing in sandbox, not all the data from production. Reducing the amount of data that is copied to sandbox can significantly reduce the sandbox copy time.

The sandbox template editor understands the object relationships defined in your org’s schema. Some objects are always included because they’re required in any org. As you select objects to copy, the editor ensures that the associated required objects are added.

To access sandbox templates:
  1. From Setup, enter Sandboxes in the Quick Find box, select Sandboxes, then click the Sandbox Templates tab.
  2. Click New Sandbox Template or click Edit next to an existing template you want to modify.

Importing Test Data

You might think it’s more convenient to use a Partial Copy or Full sandbox, and simply avoid having to load data, but that’s not necessarily better than loading test data. Data on the production org changes all the time, so anything you’re repetitively testing can give you unexpected results. Static data provides consistency.

Generally, it’s better to load a small, representative set of test data into your Developer and Developer Pro sandboxes. When functionality changes unexpectedly, it’s easier to pinpoint where the problem occurred when the data is static. Developer and Developer Pro sandboxes also have a shorter refresh cycle.

Most people load data using CSV files and the data loader. For more information, see Data Loader.


There are other data loaders available on the AppExchange. Some add more functionality and usability over the standard Salesforce Data Loader, and you are encouraged to try them out.

If you’re loading large sets of data, you can use the Force.com Bulk API. The Bulk API and supporting web interface allows you to upload and create import jobs, monitor and manage jobs, and receive notifications when the jobs complete. For more information, see Loading Large Data Sets with the Force.com Bulk API.

Managing Sandbox Users and Logins

Anyone with a production login can log in to a sandbox. Although most users in the production org probably aren’t aware of the existence of a sandbox, you probably don’t want them poking around your development environment either. To manage access, you can deactivate production users in sandbox. That works out well, because the deactivated production users make room for developers, who usually don’t have a login to the production system, but need a login to sandbox. This user license trading is necessary, because you have a finite number of licenses.

The easiest way to give developers a login to sandbox is to create them as users in production, but don’t activate them until needed. After creating or refreshing a sandbox, deactivate production users who don’t need access and then activate the developer users. Just make sure that the user you deactivate in sandbox isn’t someone who logs in to that environment.

All licenses are copied from production to sandbox. If a new license is applied in production and you want to apply it to sandbox, you must refresh with the sync tool (see Match Production Licenses to Sandbox without a Refresh ). If you don’t refresh, you can lose your work.

When you create a sandbox, all email addresses, except the sandbox creator, are modified so that people don’t receive emails from sandbox testing. Note that email delivery defaults to off, so if you need to test automated emails from Apex or workflow rules, you must turn this setting on. Not only are emails not sent, but unit tests fail when Messaging.sendEmail throws exceptions.

Share Time Estimate

Having trouble with your challenge verification?

Here are some tips:

  1. Check for typos (hey, it happens)
  2. Try using a new Developer Edition (existing customizations can interfere with the validation)