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!