Play in Your Salesforce Sandbox!

I love the Road Runner cartoons! Somehow, the very fabric of space and time seems to twist and fold to the liking of this Jedi Master bird. But most of us can relate much more to our buddy Wile E. Coyote. The only law that seems to cater to Wile E. (and us) is Murphy’s Law, where everything that can go wrong WILL. But, I think that good ‘ole Wile E. would have had his fill of Herb-Crusted Roadrunner, if he had access to a Salesforce Sandbox environment: A place where he could properly test his painted tunnels and Rube Goldberg contraptions before trying them out in the real world and ending up at the bottom of a ravine. Let us learn from the mishaps of our “Canis latrans” friend and explore the values of Sandboxes in Salesforce!

Salesforce provides you with a set of test environments that look and act almost identical to your live or “production” org of Salesforce. These environments are copies, or “snapshots” of your production org. But, they are completely segregated from your production org and can’t affect your production structure or data.The idea is that you can use these test environments to experiment with new features, test ideas, install and play with apps, and most importantly, make mistakes without hurting your production environment.

We’ll provide some nuts and bolts, but first, let’s explore why we should even use Sandboxes. Here are some use cases:

• You have a new volunteer who has a lot of database management experience but hasn’t used Salesforce. Create a sandbox and tell them to go wild! If they severely mess things up, don’t worry. You can refresh the sandbox and start over.
• You have just added some new features to your production org and need to train staff on them. Create or refresh a sandbox, give them your documentation (you did create documentation, didn’t you?) and have them learn without risking your important data.
• You just heard about a killer app on the App Exchange and want to see if it lives up to the hype. Download it into a sandbox, so you can play around with it before bringing it into production.
• You need to import some data but are unclear how it will affect your existing data. First, import a sample of it into a sandbox and let it interact with some test data.
• A developer is building a new feature for your org. Have them build it in a Sandbox. If all of the kinks are worked out, the developer can “deploy” the features into your production org straight from the sandbox, rather than building them a second time from scratch. More on deploying from a sandbox here and here.

Now for some Nuts and Bolts:

Basic Tips:

• To find your sandboxes click on “Setup” and type “Sandboxes” into the ”Quick Find” box.

• Click on “Sandboxes” from the results.
  • Here you’ll see how many sandboxes, and what types of sandboxes you are provided with.

• There are four types of sandboxes. Depending on which edition of Salesforce you have, you will be provided with different quantities of each sandbox type. Each sandbox type has different characteristics, allowing you to use them for various purposes.

• Important notes about the chart above:
  • Developer Sandboxes only copy over “metadata” or the underlying configuration and settings of your org. Records like contacts and accounts, do not copy over. You will need to create some test records in the sandbox or plan to import records using an import tool.
  • Partial sandboxes allow you to choose a subset of records from your choice of objects to copy over with the metadata. Click here for details about setting up sandboxes and using “templates” for partial and full sandbox set up.
  • Full sandboxes copy your metadata and all of your records. Talk to your account representative about license options.

TIP: Plan ahead when preparing to work in a sandbox. If you need to use one in a couple days, create/refresh it today. Sandboxes can take hours, days, or even more than a week to process!

• Logging in:
  • Go to test.salesforce.com to get into a sandbox.
  • Add “.[Sandbox Name]” after your username
    • Example: If your sandbox is named “testbox” and your username is “me@email.com”. The sandbox user name is “me@email.com.testbox

TIP: Have multiple staff/volunteers needing access to sandboxes? Create a separate one for each person. Name the sandbox after the name of each user so everyone is clear which box they should use.

Advanced Tips:

• Note that refreshing a sandbox erases any changes made in that sandbox and replaces it with the most recent version of your production org. Be careful!

TIP: Have many users accessing common sandboxes on a regular basis? Set up a standard refresh and release calendar so that people know when to expect their modifications to be overwritten. Set up a communication method that precedes the refresh so that users can request a delay or finish up their work before you refresh.

• In order to protect users from receiving unnecessary emails from sandboxes, all email addresses are modified during creation/refresh. All “@” symbols are replaced with “=” symbol (me=email.com). If you need to test a feature that includes emailing a user, you must manually go to the user settings and revert their email back to normal.
  • Email addresses in imported records are not changed. If you are creating a partial or full sandbox consider changing or deleting email addresses.

TIP: As of Spring ‘16 release, a single Apex class can be fired upon completion of sandbox creation/refresh. You can use this to run a script that empties all email fields in records or anonymize other sensitive data. See page 388 of the release notes for more detail.

TIP: Are there a bunch of little details that always need to be fixed or set when you refresh sandboxes to ensure that they work as you need them to for testing, etc? Document “post-refresh procedures” so that you and others can remember how to configure your sandboxes correctly every time.

Other Resources:

• Salesforce Help documentation for sandboxes starts here. Follow the links in the left column to read through all of the documentation.
• Much of this content was provided through a great session at Dreamforce ‘16. Look for the slide deck in the feed. Thanks to Salesforce staff Rachel Beard and Christopher Marzilli for letting me use it here.
• The Trailhead series has modules about Sandboxes. This is a great way to start digging in…pun definitely intended!