In this video, you’ll learn about different types of Salesforce Sandboxes, tips on testing in sandbox, and how to make sure your customers are not impacted.
You may have heard about Salesforce Sandboxes, and wondered “how do I get one, and how do I use it?”
Or maybe you are a more experienced Salesforce Administrator, looking for tips on some things to consider (and what to watch out for) when testing in a Salesforce Sandbox
In this video, we’ll go through the different types of Salesforce Sandboxes that are available, some tips on testing in sandbox, and some things to check for before you proceed with your testing, to make sure that your customers are not impacted.
Lets start with a Definition. What exactly is a Salesforce Sandbox?
Salesforce Sandboxes are test environments that Salesforce provides as a “safe space” for testing different Salesforce configurations, new apps, or significant changes to your setup
There are three primary types of Sandboxes available from Salesforce:
- First, a Partial Sandbox, which is a Salesforce Sandbox that includes a copy of your production org’s configuration (including metadata) and a sample of your production org’s data (but typically just a small portion of your total data).
- Second, a Full Copy Sandbox, which is a complete replica of your Production Salesforce Org’s data and configuration.
- Finally, there are Developer Sandboxes, these are more isolated environments for development and testing, that usually do not have a copy of any of your data.
The Sandbox types which are included in your Salesforce subscription level, how often a sandbox can be “refreshed”, and other details can vary quite a bit, so we recommend consulting the Salesforce documentation as well as your Production Org for further details. To check in your Production Org, navigate to Salesforce Setup > Environments > Sandboxes. Here you will see your Available Sandbox Licenses.
Why should you test in a Salesforce Sandbox?
Salesforce orgs can be extensive, with many different areas of data and multiple applications. Sandboxes give you a chance to test changes without impacting your operations or data in your production Salesforce org.
Even seemingly “minor” changes like adding a new Process Builder may have impacts on parts of your data or Salesforce configuration that you had not considered. Testing in a sandbox first gives you a chance to make sure any new automation and customization works as you are expecting it to work, and that it doesn’t have any unintended effects that you had not considered.
A Sandbox also helps you to customize Salesforce more effectively, by giving you more freedom to experiment and try different approaches, without worrying about how changes would affect your users or data.
What should you consider when using a Sandbox?
If you are using a Full or Partial Copy Sandbox, keep in mind that the Sandbox contains an either complete or a partial copy of your real customer data. This may include your customers credit card and bank account information. So you should be careful to update things so as not to inadvertently charge customers, send emails to customers, or otherwise affect your customers via actions that you take in the sandbox.
Sandboxes are separate orgs, with a different Org ID from your Production Org. After a sandbox is created, data does not update or sync between your Production Org and your Sandbox org. So changes made in either Org will not be reflected in the other Org.
Remember to log in to your sandbox using the following URL: https://test.salesforce.com, as well as your sandbox username. This is your regular username with the sandbox name added to the end after a dot, for example if your sandbox is named partial, it would be email@example.com.
Next let’s go over Creating and Refreshing Sandboxes
When it comes to creating and refreshing sandboxes, there is a lot to know. So much that we are not going to cover the details in this video, just please keep in mind these two things:
- It can take days or even weeks to create or refresh a sandbox, depending on the size and complexity, so build that into your planning.
- Remember that when you refresh a sandbox, it makes a copy of the configuration from production, but it also deletes anything you were working on in Sandbox that doesn’t exist in production. So be careful if you are doing significant development or customization, you don’t want to lose your work!
Lets go over a few Email Considerations
- Sandbox email deliverability, which you can find by navigating to Salesforce Setup > Deliverability, is set to “System Email Only” by default. You can change this to “All Email” if you would like to test certain email features, but BE CAREFUL! Your customer emails are going to be present in non-Developer sandboxes.
- Sandboxes change User emails, adding .invalid on the end. So if you want users to receive system generated emails, update their email addresses to remove the .invalid
- Sandboxes DO NOT attach the .invalid to Email addresses in your Leads and Contacts. So use the Email Deliverability setting that we went over previously to make sure you don’t email them, or you can remove their email addresses entirely from the sandbox to be 100% safe.
Lets talk about some Other Sandbox Considerations
We will be using our application Chargent, which provides payment integrations to Salesforce, as an example for these next recommendations, but these types of precautions apply to many Salesforce Sandboxes and other Salesforce Applications as well.
- First, Licensing. Like most Salesforce AppExchange apps, Chargent gives you a site license when installed in Sandbox. This means that you do not need to assign Chargent user licenses to your Salesforce users in a Sandbox. In addition, you can test out all of the premium features of Chargent without a license key.
While this open site license is a useful Sandbox feature, it is also important to keep in mind for your testing. You may not have access to all features in production that are available in sandbox, and you may need to complete some additional testing in production where user licenses need to be assigned. It is best to build in a bit of extra time to test in production and avoid any surprises with the different permissions.
- Second, lets go over Batches and Scheduled Jobs. Is anything running that you copied from production and should be shut off?
For example, Chargent has a recurring billing job that runs daily. We recommend checking your Sandbox after it is created to see if this could be processing any real customer records in a way that you would want to prevent.
Often when you refresh a sandbox, Scheduled Apex Jobs will not be running. But we recommend to go to Salesforce Setup > Scheduled Jobs to check and be sure that any scheduled jobs are not running in your Sandbox.
- Third, lets talk about Chargent Payment Gateways. As a security precaution, when running in Sandbox, all Chargent Payment Gateway records will send to the test payment gateways, regardless of whether you set them up as test or live. The “Test Endpoint” checkbox field is effectively disabled, so transactions are always sent to a test endpoint whether it is checked or not.
HOWEVER, there is a workaround in the sandbox which we have provided, for when you want to run a few real credit card transactions at the end of your testing, just prior to going live. You can use the “Endpoint Override” field on the Gateway record to override our setting, and send transactions to a live server from a Salesforce Sandbox.
If you are creating a Full or Partial Copy sandbox, the endpoint override setting will be copied from your production org if it is populated there. So it is a best practice to remove the Recurring Billing batch, and to remove that endpoint, to make sure no live transactions get sent.
- Next it is important to know that Test data is not equal to real customer data. If you create some test data to supplement what you have in a sandbox, keep in mind that data that you make in a spreadsheet will often be much cleaner than real data, especially if you are moving that real data from another system.
Whenever possible it is a good idea to test in the sandbox with sample, real data from the system you are going to be running. (Just keep in mind the email considerations we talked about earlier).
What do we mean that test data is cleaner than actual data? Consider real data entered in a system by multiple people, and the variants of abbreviations, country names and more that could be different on different records. In addition, there may be incomplete, blank or transposed fields. When you create test data in a spreadsheet, you are unlikely to have these same inconsistencies and mistakes.
Phew, that was a lot of things to consider when working in Salesforce Sandboxes. But we bring them up so you don’t have to learn about these issues the hard way.
Just one more pitch for using Sandboxes, then we will wrap up this video.
In order to have a successful go live with Salesforce, Chargent, and other Salesforce apps, testing is critical. Especially for Chargent, as it is a financial application, and aspects of both Salesforce and payment processing can be complex at times. Successful and error-free payments are critical to any business or nonprofit organization, so it is best to work through any configuration in the testing phase.
We therefore urge you to plan for a real Salesforce Sandbox testing phase as part of your launch of Chargent in your Salesforce environment. This includes test and live payments in both a Salesforce Sandbox and your production Salesforce org as well. These testing guidelines are what we have seen resulting in the most successful implementations of Chargent, especially when moving from other billing or payments software.
Check out part 2 of this video, “How to Test Payments in Salesforce,” for an in-depth video on the specifics of testing financial transactions with Salesforce and Chargent.