Salesforce sandboxes give you more agility and reduce the risks. They make it safer for you to make changes and by doing that allow Salesforce developers, admins, and citizen developers to make changes more quickly and easily. Since it is isolated from the production org, it lets you write code, build whatever configurations you want, perform changes or integrations you want without affecting your production org.
What are the different types of Sandboxes in Salesforce?
There are 4 types of Salesforce sandbox environments:
• Developer sandbox
• Developer Pro
• Partial Copy
• Full sandbox
Developer Sandbox
Developer sandbox environments are intended for coding and testing by a single developer. Multiple users can log into and share a single Developer sandbox, but the primary purpose of a Developer sandbox is to provide an environment in which changes under active development can be isolated until those changes are ready to be shared. Developer sandboxes copy all of your production organization’s metadata, or Setup data. This includes custom settings, custom object definitions, Apex classes and triggers, Visualforce pages, reports, dashboards, price books, and so on.
Developer sandboxes provide a limited amount of file and data storage, which is enough for many development and testing tasks.
Developer Pro Sandbox
Developer Pro sandbox environments types provide the same functionality as Developer sandboxes types do, with increased file and data storage. With the added storage, a Developer Pro sandbox can host larger and more complete data sets, so you can use it for additional tasks such as data load and integration testing and user training.
Partial Sandbox
Partial Copy Salesforce sandbox types include all of your organization’s metadata and a sample of your production organization’s data that you define by using a sandbox template. To create a Partial Copy sandbox, you must apply a sandbox template at creation time.
A Partial Copy sandbox is, at its base, a metadata copy of your production organization, just like Developer and Developer Pro sandboxes. In addition, the sandbox copy engine samples data from your production organization based on what is defined by a sandbox template. For each selected object in the sandbox template, the sandbox copy engine samples up to 10,000 records. For example, when you use a template that includes only Accounts to create a Partial Copy sandbox, up to 10,000 Account records are copied into the new sandbox, but no other records are copied.
The sandbox copy engine has a special copy strategy to handle Partial Copy sandbox creation. The copy strategy understands the data relationships that are defined in your production organization’s standard and custom object schema. The copy strategy ensures that sample records maintain valid relationships as defined in your production organization’s standard and custom object schema.
For example, if you create a sandbox template that includes two custom objects that are called Master and Detail, and these objects have a Master-Detail relationship, the copy engine ensures that every sampled Detail record points to a Master. The copy engine also understands required relationships between objects, whether they are Master-Detail or required Lookup relationships. The copy engine samples the master records first and then uses the IDs of the master records to sample related detail records.
When you use sandbox templates to create valid subsets of your organization’s data, you can use Partial Copy sandboxes for virtually any development, testing, or training purpose. The only task for which they aren’t well-suited is full performance and load testing.
Full Sandbox
Full sandbox environments are a replica of your entire production organization and all its data, including standard and custom object records, documents, attachments, code, settings, and so on.
When you create a Full sandbox, you can apply a sandbox template to limit the data that is copied, so that your sandbox contains only the records that you need for testing or other tasks. For example, you can omit confidential or sensitive data if it’s not needed for testing. Create a sandbox template that includes everything except the sensitive data. When you apply a sandbox template to a Full sandbox, the sandbox copy engine copies all of the records for the selected objects in the template. For example, when you use a template that includes only Accounts to create a Full sandbox, all of the Account records are copied into the new sandbox, but no other records are copied.
When you create a Full sandbox, you also have to decide how much field tracking history and Chatter activity to include.
The default is to omit field tracking, but you can include up to 180 days of field tracking. This might be an excessive amount of data if you track field history for many objects in your production organization.
Chatter activity data can be extensive, which can add a significant amount of time to your Full sandbox copy.
Limit the amount of field history that you copy, and copy your Chatter data only if you need it for your testing use cases.
You can use Full sandboxes for many purposes, but the size of the sandbox and length of the refresh interval don’t produce an environment that stays current with your production organization. We suggest that you use Full sandboxes for data load testing, integration testing, user acceptance testing, performance and load testing, and staging purposes. In particular, this environment is the only one that can support full performance and load testing.
Conclusion
Developers use sandboxes for staging, performance testing, UAT, SIT, training, etc. as part of their development process to create and test changes. These when used together with scratch orgs and Salesforce DX’s source-driven development drive developer productivity and collaboration during the development process. Packaged development happens. Flosum, gives developers full-scale power tools they need, in the ways they’ve always wanted.
