One of the most popular blog posts in the Longshore Consulting blog archives is this article, "5 Tips on How to Use Salesforce Sandboxes for Nonprofits" (re-posted below). While it's still a great article, a few things have changed since I first wrote it two years ago, so I thought I'd republish it here to make it easier to find on this site and to offer some new tips and resources.
Here are four additional big improvements and tips to help you use sandboxes with ease:
1. Nonprofits now get a free Partial Sandbox! This is an amazing way to include some data in your sandbox so you don't have to type a bunch of test records. Not sure how to do this? Check out this #AdminHour, starting at 23 minutes in, where I walk you through how to set one up (there's also a ton of great tips about how to test whether your nonprofit is ready to switch to Lightning in that webinar recording, by the way).
2. You can now learn more about Sandboxes with Trailhead! Get tons more Sandbox details and earn some awesome points, and be sure to check out the extensive list of resources to learn more, on this unit of the Application Lifecycle Management trail.
3. There's now an Apex class screen that comes up when you're creating a sandbox that's a little confusing: just ignore it and click 'Create.'
4. Sandbox access: if you have a user who can't access the sandbox, you'll typically need to go in and: a. change their email to their actual email address, b. have the user click through on the email getting them to verify the change to their email address (and on the subsequent screen have them log in with their sandbox username, i.e. being sure to append '.sandboxname' to their email address), c. confirm with the user they're now able to log in to the sandbox, and if not send them a password reset (from within the sandbox setup screen), and d. tell the user to set their sandbox password to the same as their production password for ease of use. Ideally, before generating the sandbox, you should make sure all users are created in production to have as few issues as possible with sandbox logins. Also be sure to have people login to the sandbox the day *before* your staff training so you don't have to spend precious group time troubleshooting login issues.
Good luck on your sandbox journey! For ongoing tips and Salesforce support in an interactive format, be sure to sign up for #AdminHour, which is free the first and third Thursday of every month at 10am PT/1pm ET. Hope to see you there!
5 Tips on How to Use Salesforce Sandboxes for Nonprofits
Salesforce Sandboxes are super fun and helpful places to test out changes to your Salesforce system before you put those changes in place in your live production environment. But when and why should you use them? What do you do with them if they’re blank? When should you refresh your sandboxes? Here are five tips to help you use them without fear: 1. Don’t be afraid – they’re meant to be played in! Just click: Setup –> type ‘Sandboxes’ in the Quick Find –> click ‘Sandboxes’ –> click ‘New Sandbox.’ You’ll likely have Developer and Developer Pro sandboxes available (assuming you’re a nonprofit). Type in an easy name to append to your Salesforce user name, like ‘test.’ Remember when you log in to go to https://test.salesforce.com/. To log in, use: email@example.com and your regular password. 2. Discuss before refreshing. When you refresh a sandbox, you push a new copy of your production environment’s metadata into the sandbox, completely writing over everything that’s in the sandbox already. In English, that means if you added a new field in your Salesforce instance called ‘My New Field’, then refreshed the sandbox, you would now see that field in the sandbox (but not the records or values you had entered into that field). If you have more than one Salesforce administrator at your organization (like most nonprofits), be sure to communicate clearly before you refresh the sandbox. Otherwise, if you refresh it without asking, you could erase the workflow rules, applications, or code another team member is testing out in the sandbox. 3. Use one sandbox as a documentation resource – after all, nonprofits get 7 free sandboxes! Just be clear in the sandbox description field. For example, one sandbox could be named ‘backup’ and the Description could read, ‘Backup of our organization’s Salesforce instance as of February 2015, before we upgraded to the Nonprofit Starter Pack v 3.0, in case we want to refer to any of the configuration before upgrade.’ Note it’s a good idea to log in to your backup sandbox at least once to check all your metadata (configuration) is there before you perform any major changes in production. 4. Know what can and can’t be moved into production. Apps from the app exchange, for example, can’t be moved, but it’s still a really great idea to test them in the Sandbox to see if they’re a good choice for your organization. The full list of what can be moved using a change set can be found here. 5. Quickly create test data if your sandbox is empty. Unless you pay for a partial or full sandbox, your sandbox will not have any records, so be sure to quickly enter a few test records when you login for the first time after creating or refreshing your sandbox. Remember to start with Organizations, then add a Contact, and then add a record to the new custom object you just created if needed (e.g. lookup relationships). This part can be frustrating because each time you refresh the sandbox you’ll need to start over and create these test records again. To make it easier, I keep a few test names on hand (think ‘Kermit de Frog’ and ‘Test Testerson’) and only fill in the required fields. Have any other tips or suggestions? Leave them in the comments!
Missy (@missylongshore on Twitter and Periscope) writes this blog just for you!