Use Sandboxes to Manage Change

Learning Objectives

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

Use sandboxes for training.
Test a release in your sandbox.
Recall one option for deploying changes from a sandbox to production.

Putting Your Sandboxes to Work

Learning how to set up sandboxes is the easy part—now let’s talk more about why you actually need these helpful tools in the first place!

Sandboxes are the perfect place to test all sorts of things, but there are three ways you may use them the most: for training, to test releases, and to create or add new features before releasing them to production.

Remember that you can log in to your sandboxes by going to https://test.salesforce.com. Use your username with a period and the name of the sandbox at the end—like gorav@nomorehomelessness.org.AppTesting—and your password on the day the sandbox was created.

Use Sandboxes for Training

Good training is a key part of NPSP and Salesforce adoption, so when it’s time to train your users, it’s important to follow the old coaching adage and practice like you play—get hands-on with as realistic a training environment as possible.

When your real-world data is important for training, you may want to use a Partial Copy or Full sandbox.

Otherwise, you can load sample data into a Developer or Developer Pro sandbox. Check out How I Solved This: Populating Sandboxes with Flow for an example of how a group of awesome admins were able to create a tool to seed a Developer sandbox with test data.

Use Sandboxes to Test Releases

You’ll also use a sandbox to preview and test features included in new Salesforce and NPSP releases before they’re deployed to production orgs.

Here’s when you can start testing:

New NPSP features are released to all sandboxes about a week before release to production begins.
Salesforce platform release previews start about four to six weeks before a release to production begins.

For Salesforce platform releases, you’ll need to make sure you have at least one preview sandbox for the entire preview period. How do you make sure one of your sandboxes is a preview sandbox? It’s all about timing.

The Release Milestones Infographic group and Salesforce Sandbox Preview Guide linked in Resources can help you set your timeline and determine if your sandbox is preview ready. And be sure to check out the Release Readiness Strategies module on Trailhead and the De-mystifiying the Sandbox Preview video, both linked in Resources, for more details.

Some features in each NPSP and Salesforce platform release will be enabled automatically. For others, you can choose if you wish to enable and use them. Once the previews are in your sandbox, here’s what to do in either case:

For a feature that will be enabled automatically, try the new feature and determine if you need to train or inform your users before release.
For a feature you can choose to enable, determine if you want to enable it, learn how to turn it on, and practice configuring it.

With release preparation in your sandbox, you’ll be ready for release day no matter what new features arrive.

Use Sandboxes to Deploy Changes to Production

Sandboxes are also the perfect place to create your own new objects, apps, and other features. The best part? You can take most of those new elements and deploy them right to your production org.

There are a few ways to do this, but we won’t review them all here. One important tool we want to mention, though, are change sets. Change sets allow you to deploy modifications to a sandbox made in the Setup menu—like adding a new object or app, but not data—to production with clicks instead of code.

To learn about all of the options for getting your hard work from your sandbox to your production org, check out the Deploy Your Changes link in Resources. You’ll find instructions for using change sets and be able to learn about other code-focused tools. And if you get stuck, you can always turn to the NPSP community for help.

In the next unit, we’ll talk about that community and how you can contribute to it.