Does this situation sound familiar?
Your organization has been operating on Salesforce for a while. Although things are running great, you’ve decided that you want to make a few adjustments — install a new app, tweak a few configurations, or even play around with different features. Your team makes a few changes here, a few changes there, and deploys them across the account.
Immediately, you realize that things aren’t working as you expected, and you can no longer return to your previous version. What happened?
Well, many things may have happened! Your changes may have impacted one of your automations, or maybe one of your configurations caused an error in the system. Debugging is time-consuming and difficult, but the entire situation could have been avoided by testing first in a Salesforce Sandbox.
In this article, we’ll explain how to test in Salesforce Sandboxes, the different types of sandboxes, and when to use each one. We’ll also provide six expert considerations you should keep in mind when working in a sandbox environment.
What Is a Salesforce Sandbox?
Sandboxes are environments that Salesforce provides as a “safe space” for testing or experimenting with new apps or significant changes to your setup. It enables you to create copies of your production (live) environment for testing, training, and development purposes.
A Salesforce Sandbox allows you to apply changes without worrying about those changes affecting your current production org. Although the two may seem similar, a sandbox is not a data backup, but instead is a replica of your production environment, as it was on the date the sandbox was created.
Why Should I Test in a Salesforce Sandbox?
There is one significant benefit to using a Salesforce Sandbox — it is independent of your production org. In other words, changes made to the sandbox do not affect the current production environment, and changes to the production org don’t affect the sandbox. Even if you completely change the sandbox environment, your production organization remains intact.
Salesforce organizations can be extensive, with significant data, multiple additional applications layered on top of your Salesforce org, and automation.
Creating and deploying a Flow, for example, may seem like a minor change, but even small actions can impact large parts of your data or your system configuration. When testing in a sandbox though, you can ensure that any new automation or customization is working exactly how you expected before deploying it to production.
Different Salesforce Sandbox Types
Salesforce offers four different sandbox types. Each one has a different intent, so it’s important to choose the right one depending on your particular situation.
| Sandbox Type: | Intended For: | When To Use: |
| Developer Sandbox | Development and testing in an isolated environment. | Development and testing tasks. |
| Developer Pro Sandbox | Development and testing in an isolated environment. | Development and quality assurance tasks, integration testing, or user testing. |
| Partial Copy Sandbox | Used as a testing environment. | Quality assurance tasks, such as user acceptance testing, integration testing, or user training. |
| Full Sandbox | Used as a testing environment. | Support performance testing, load testing, or staging. |
Which Type of Salesforce Sandbox Should I Use?
The Developer and Developer Pro Sandboxes have low storage capacities, so they are ideal for smaller teams working on projects with minimal data requirements. If you have a larger team or are making more robust changes that require data samples, you might be better off with a Partial Copy or Full Copy Sandbox.
The Developer Sandbox is great for small projects like testing new features or fixing bugs within your production org. The Developer Pro can be used for similar projects, as well as slightly larger projects for teams with more users and more concurrent testing.
If you’re working on projects that require some real data from your production org, a Partial Copy Sandbox is perfect. It has more storage, so you can complete projects that use more resources, such as testing new integrations or functions.
The Full Copy Sandbox is for projects that need a complete copy of your production org. It is typically used for end-to-end performance testing, load testing, and staging projects that require a lot of data or have large developer teams.
Salesforce Developer Sandbox Considerations
When developing or testing in a Salesforce Sandbox, there are many considerations you should acknowledge. The following tips will help you use your sandbox most effectively while avoiding any errors that could cause issues or derail your progress.
General Sandbox Considerations
As you create, develop, and test in new sandbox environments, keep these factors in mind:
- Customer Data: For those using a Partial or Full Sandbox, it is important to remember that the sandbox organization contains either a complete or partial copy of your real customer data. This can include payment information and email addresses, so be careful when making updates to avoid inadvertently charging them, sending them accidental emails, or affecting them in another way.
- Syncing: Sandboxes are separate organizations, and will have a different Org ID than your production org. When a sandbox is created, data does not update or sync between the two organizations. In other words, changes made in one environment will not reflect in the other. You will either need to deploy changes made to the sandbox into your production org or refresh the sandbox to sync with your updated production org.
Creating or Refreshing a Sandbox Environment
There are several considerations you should take into account when creating or refreshing your Salesforce Sandbox. Failing to consider these factors can result in project delays or lost work.
- Estimated Completion Time: Depending on the size and complexity of the project, it can take hours, days, or even weeks to create or refresh a sandbox that includes larger data sets. The estimated completion time is driven by several factors, including the level of customization, data size, number of objects, server load, and your specific configurations.
- Refreshing: Be careful when refreshing your Salesforce Sandbox. When you refresh, a copy is made from the current production environment. This means you will lose any data or configurations you may have been working on in the sandbox if those changes don’t exist in the current production org.
Handling Email Addresses in a Sandbox
Knowing how your Salesforce Sandbox handles email addresses is critical. Managing email addresses improperly in a sandbox environment can result in the inadvertent sending of emails to your customers or contacts.
- Email Deliverability: By default, sandbox email delivery is set to “System Email Only.” You can easily change this to “All Email” by navigating to Salesforce Setup Delivery if you want to test specific email features. Caution is necessary when doing so, however, since all of your customer emails will now be present in non-developer sandboxes.
- Appending Email Addresses: User emails are automatically appended with a .invalid path. If you want users to receive system-generated emails from the sandbox, update their email addresses, and remove the .invalid tag. Keep in mind, however, that Sandbox will not attach the .invalid path to email addresses in your Leads and Contacts. For these cases, use the “System Email Only” deliverability setting or delete their email addresses from the sandbox entirely to ensure that you don’t email them.
Managing Test Data
As you’re working in a sandbox, remember that test data is not equal to real customer data. Test data created solely for the sandbox (such as data created and kept in a spreadsheet) is often much cleaner than real data, especially if you are moving real data from another system.
Unlike test data, real data is usually entered into a system by multiple people — variants of abbreviations, country names, and other entries can vary on different records. Occasionally, the record may have incomplete, blank, or transposed fields. When data is created on a spreadsheet, however, it is unlikely that you will have these same informational inconsistencies and mistakes.
Whenever possible, it is recommended to test in the sandbox with real sample data from the system you plan on running. By doing so, you can ensure that customer data in the test environment truly reflects the production org and that the sandbox system performs the same way it would in a live situation.
Planning for Salesforce Sandbox Testing
Testing is critical to the proper implementation of Salesforce, and Salesforce apps such as Chargent. The tips we’ve provided in this article, along with our support and documentation, will help you use Salesforce Sandbox with skill and confidence.
With applications dealing with finances or payments such as Chargent, it is especially important to plan for a sandbox testing phase as part of the app’s launch in your Salesforce environment. This includes making test and live payments in both your sandbox and production organizations. In our experience, these testing guidelines have led to the most successful implementations.
Want to play around with a Sandbox? Install Chargent and take us for a free 30-day trial and see how easy it is to improve your payments and accounts receivable processes directly in Salesforce.
FAQ: Salesforce Sandboxes for Testing & Development
How Do I Create a New Sandbox?
Creating a new sandbox is relatively easy. Go to Salesforce’s Setup page, where you can search for Sandboxes in the Quick Find box. Click “New Sandbox Template” (or you can also edit an existing one). Give your sandbox a name and description, add objects from the available list, and click “Save.”
How Do I Refresh a Sandbox?
Refreshing a sandbox will sync the data in the sandbox with the current data from your live production org. Use the Quick Find box on the Salesforce Setup page to search for your sandbox. If your sandbox is available for refresh, there will be a refresh button next to the name of your Sandbox. Developer and Developer Pro Sandboxes can be refreshed once per day. Partial Copy Sandboxes can be refreshed every five days, and Full Copy Sandboxes can be refreshed every 29 days.
What Is the Difference Between a Salesforce Developer Org and a Sandbox?
Developer Edition orgs are similar to production orgs, but they are strictly used for developing new products. They may include basic test data, but they do not contain business-specific data. Depending on which type of sandbox you use, it may contain data copied directly from your production org. Therefore, it’s much more effective for testing business-specific integrations and functions for your organization.
Developer Edition orgs are good for businesses that want to create a Salesforce app or a managed package to be sold commercially. The Partner Developer Edition org is also available for larger teams that need to share source code or that expect more than one developer to work on a project at a time.
How Many Sandboxes Can I Create?
Your sandbox limits will depend on which Salesforce tier you purchase. If you have the Professional edition, you’re allotted up to 10 Developer Sandboxes. With an Enterprise subscription, you can create up to 25 Developer Sandboxes and one Partial Copy Sandbox. If you require more sandboxes, you can purchase them as add-ons. If you exceed your sandbox allocations, you’ll get a notification email from Salesforce and a grace period of 30 days to purchase additional licenses or remove the excess sandboxes before they are locked.
How Do I Delete a Sandbox?
You can delete a sandbox from the Salesforce Setup page. Search for your sandbox in the Quick Find box, click “Del” next to the sandbox name, and confirm on the popup.
You can only delete a sandbox after it has passed its refresh period, so you may need to wait for the refresh period to end before the option to delete becomes available. If you delete a sandbox and change your mind, you must contact Salesforce within about five days of initiating deletion to recover the data.
