Salesforce Sandbox is a crucial development and testing environment for testing changes before deploying them to production. Refreshing the sandbox is essential for developing new features, testing applications, and troubleshooting production errors. It offers developers a worry-free deployment experience without impacting live customer data.
Types of Salesforce Sandboxes
Salesforce offers different types of Sandboxes that cater to different use cases and needs. Here are the four main types of Salesforce Sandboxes:
- Developer Sandbox: A Developer Sandbox is a basic type of Sandbox primarily intended for development and testing. It provides an isolated environment for developers to build and test customizations without affecting the production environment. It’s a good option for smaller organizations or individual developers who don’t need the advanced features of other Sandboxes.
- Developer Pro Sandbox: Developer Pro Sandbox’s main difference from Developer Sandbox is the data and file storage limits, which are both equal to 1 GB. It’s a good option for testing large-scale customizations, integrations, or data migrations.
- Partial Copy Sandbox: A Partial Copy Sandbox is a Sandbox that includes a subset of data from the production environment, which can be customized based on specific criteria. It’s ideal for testing scenarios that require a realistic data set, such as integration or user acceptance testing.
- Full Sandbox: A Full Sandbox is a complete copy of the production environment, including all metadata, configuration, and data. It’s ideal for testing complex scenarios, such as major upgrades or deployments, that require a complete and accurate copy of the production environment. The Full Sandbox is also useful for performance testing and training purposes.
When you use Partial Copy Sandbox, you are required to use a Sandbox Template. Sandbox templates allow you to pick specific objects and data to copy to your Full or Partial Copy sandbox to control the size and content of each sandbox.
It’s worth noting that some objects will be included in the Template by default as they are required in any org. Any associated required objects are also included in the Template. For example, if an object that is a child in master-detail relationship, is added, the parent will be required.
For each selected object in the template, the sandbox copy engine will select up to 10,000 records. The copy strategy follows the object relationship logic, so if there are objects related through master-detail relationships, then records of both objects will be copied.
Note! There is no way to select the range of records that are copied when the sandbox is created or refreshed.
Sandbox Refresh Strategy
Pre-actions: Document sandbox configurations, define sensitive data, document existing integrations, and backup sandbox data before refreshing.
Post-actions: Configure sandbox settings, sensitive data, re-establish integrations, reactivate scheduled jobs, test your sandbox functionality, and update documentation
- 1. Custom settings are nothing but normal records. so we can import or export it using a data loader and inspector.
- 2. Metadata is configuration only so it will be copied from production automatically on refresh.
- 3. Remote site is also config it will be copied from production.
- 4. also need to configure Named credentials if there is any.
but here, is the main concern all data and configuration will be of production so we might need to set it according to the sandbox environment.
For example, we have some integration related Information in custom settings or custom metadata in that case production will have product information for external system (external system’s production) while refreshed org needs some testing environment Information of external system.
In the same way some configuration or data might be different from production so we need to change it accordingly after the refresh.
- Full sandboxes can be only refreshed every 29 days.
- For full sandboxes plan for a minimum of 48 hours as the timing of the refresh is dependent on the salesforce Queue and also amount of data
- Do not plan your sandbox refresh during Salesforce spring, summer and winter release dates and times.
- Do not do sandbox refreshes during your regular development times. This would create double work on the team.