While using Salesforce, it is always important to ensure utmost safety and security of your database. Users cannot afford to make the smallest mistakes while importing records within their Salesforce org, managing them, and integrating the database with an external application. In 2021, the majority of data stored by organizations is highly sensitive and should not be shared with every user working in the organization. This is why administrators are required to set up roles and permissions to different users in order to prevent unauthorized access of information.

When it comes to development and testing, it is never advisable for users to go ahead with the production org. Users need to make sure that the production and/or testing data is secure, private, and undisturbed when the processes are being carried out.

This is when a Salesforce sandbox comes into the picture.

What Is A Salesforce Sandbox?

A Salesforce sandbox is a copy of your production environment that can be used for testing purposes. This testing environment contains a copy of your records that can be modified and managed without affecting the records stored within your production environment. Salesforce sandboxes are commonly used for making necessary changes to try different configurations, developing new applications, training Salesforce users, and to serve a range of other purposes.

Salesforce sandboxes allow you to create multiple copies of your production environment and use each of them for various purposes as required. They make sure that the data stored within your Salesforce org stays undisturbed when the development and testing processes take place. It is important to remember that a Salesforce sandbox does not create a backup for your data. It is merely a copy of your production environment that would get rid of the data once the concerned purpose is served.

Why Should You Test Your Data Using A Salesforce Sandbox?

The biggest benefit of using a Salesforce sandbox is that it is independent of the production environment. Although the data is identical to that of your production org, you can work on it without worrying about the actual data getting affected. Similarly, any changes made to the production org does not affect the data stored in the sandboxes.

This provides you and your team with a freedom develop and test applications without disturbing your production org. For example, if you are willing to add a Process Builder, you can test the same in a Salesforce sandbox before deploying it in the production environment. This allows you to ascertain its functionality and the manner in which it runs before it is actually deployed.

Different Types Of Salesforce Sandboxes

There are four major types of Salesforce sandboxes – Developer Sandbox, Developer Pro Sandbox, Partial Copy Sandbox, Full Sandbox.

Developer Sandbox

This is the most common type of Salesforce sandbox and is included with most Salesforce licenses. These sandboxes allow users to create a testing environment along with a copy of metadata from the production environment. These sandboxes can be refreshed once every day and possess the file storage limit of 200 mb.

Developer Pro Sandbox

This sandbox is similar to a Developer Sandbox, the only difference being that is contains a greater storage limit. They provide users with 1 GB worth of data and file storage each. They can be refreshed once every day. A Developer Pro sandbox is included only with the Unlimited and Performance editions of Salesforce. However, it can also be purchased separately according to the user’s requirements.

Partial Copy Sandbox

A Partial Copy Sandbox not only allows users to create a copy of their Salesforce metadata but also helps them copy a portion of their production data. Here, you can use a sandbox template for selecting a sample set to be reflected into your sandbox.

A Partial Copy Sandbox is ideal for testing the new functionality on live data. It can also be used for training users in a test environment with live data. These sandboxes can be availed with purchasing the Enterprise, Unlimited, and Performance editions of Salesforce.

A Partial Copy Sandbox can be refreshed once every five days and possesses data storage capabilities of up to 5 GB. Moreover, the file storage in the sandbox is also identical to that of your production org.

Full Sandbox

As the name suggests, a Full Sandbox allows users to copy all the metadata and data from the production environment. It is the exact replica of your production org and allows you to test the complete functionality of apps and provide extensive training to new users.

These sandboxes can be refreshed once every 29 days, with the file storage being exactly similar to that of your production org. A Full Storage Sandbox can be availed of with the purchase of the Unlimited and Performance editions of Salesforce. They can also be purchased separately.

Important Salesforce Sandbox Considerations

While using Salesforce sandboxes, users are required to acknowledge certain specific considerations to optimize the performance of the sandbox. Here are some of the most important considerations to keep in mind before using your Salesforce sandbox:

Customer Data

If you are using a Partial Copy of Full Sandbox, it is important ensure that ensure that the sandbox consists of either full or a partial copy of your production org. If your production data consists of sensitive information about your customers (credit card details, bank account details, passwords, etc.) it is always advisable to be careful while making updates for maintaining the security and privacy of your database.

Data Synchronization

It is important to consider a sandbox as a separate organization and possess a unique Org ID that is different from your production org. Always remember that when a sandbox is created, your Salesforce data is not updated or synchronized with your production environment. This allows users to make changes that do not affect the data stored in the production environment.

Estimated Completion Time

According to the size of the testing/development project and its complexity, it may take you several hours, days, or weeks for creating or refreshing a Salesforce sandbox (including larger datasets). The estimated time of completion depends on multiple factors, such as the number of objects, size of the project, volume of data, server load, and other specific configurations.

Refreshing The Sandbox

It is always advisable to be careful while refreshing your Salesforce sandbox. On refreshing the sandbox, it creates a copy of your current production environment. This will lead to your losing all data and configurations you and your team have been working on using your sandbox. It is, therefore, important to save the changes in your production environment before refreshing your sandbox.

Email Deliverability

In a Salesforce sandbox, the email delivery is set to “System Email Only” by default. Users can change this to “All Email” simply by going to the setup and selecting the option of “Delivery” for testing specific email features. It is important for users to be alert while doing so as this would make all their emails appear in the non-developer sandboxes.

Appending Email Addresses

User emails in Salesforce are automatically appended with a “.invalid” path. If users are willing to receive system-generated emails from their sandboxes, they can update their email and get rid of the “.invalid” tag. However, it is important to consider that the sandbox will never attach the “.invalid” path to email addresses stored in the objects of Leads and Contacts. In such cases, it is advisable to use the “System Email Only” setting or delete the email addresses from the sandbox.

Licensing Of Application

Whenever the users need to obtain user licenses, they may need to undertake additional testing during the testing phase. During this time, it is advisable to plan adding a little extra time to the schedule for testing.

Batches And Scheduled Jobs

Before going ahead with the creation of a sandbox, it is always advisable to ensure that there are no scheduled jobs running during the testing phase. Moreover, it is advisable to identify whatever is not required for your sandbox but has been copied from the production org anyway.

Payment Gateways

It is important to note that all the payment gateway records in a Salesforce sandbox are sent to “Test Payment Gateways”, whether they are set up as “test” or “live”. In order to send the transactions to a test standpoint, the checkbox of “Test Endpoint” is disabled by default. If a user is willing to run some actual credit card transactions before going live, they can use the field of “Endpoint Override” on the Gateway Record for overriding the settings and sending transactions from the sandbox to a live server.

The Final Word

This was an overview of all the major types of Salesforce sandboxes and the considerations to keep in mind while creating or refreshing the same. While sandboxes ensure utmost privacy and security of your production environment, it is always important to be vigilant while creating these testing environments. If you are willing to keep the sandbox records private, it is advisable to mask them with dummy data while copying them from your production environment.