Sandboxes are highly beneficial developer tools, which help create copies of Salesforce org in various development and testing environments. It is easy for the individual developers and enterprise development teams to use Sandboxes for the development of different applications, do application testing, and also to train without compromise on data or applications in production org.
Sandboxes can be effectively used if you want to customize an org in various staging environments without tampering production org and the users. The developers can also set up an organization which the users can log into as well as test the features before putting them into production or testing. It is easy to log on to the Sandbox for training also by mirroring production orgs.
Creation of Sandboxes
As we have seen, developers can create sandboxes to develop and test applications easily and for training. This can be applied in various environments. It is also easy to clone one sandbox environment in order to copy the metadata to another sandbox easily. You can also easily refresh sandboxes to update content. To create and manage Sandbox:
- You can first access Quick Find box at the home page of Salesforce and then search for Sandboxes.
- All the sandboxes available will be displayed.
- You can programmatically set up the Sandboxes based on your priorities.
- Next use Salesforce CLI for creation, authorization, and cloning of Sandboxes.
- Administrators can create sandboxes and manage them using a user-friendly interface. However, as there is a need to custom mange the development environment and testing programmatically, Salesforce CLI has options for it.
- You can also easily migrate metadata between different Salesforce orgs using the deployment tool from setup.
Developer sandbox offers a limited amount of data storage and file storage, good enough for the developers to manage their development and testing activities. A typical developer Salesforce sandbox may have about 200 MB to 5 GB of data storage, and there are options like metadata only, metadata, a sample of object data etc.
Next, Partial Copy Sandbox, which includes all the metadata of organization and samples of your production org data which you can define using sandbox templates. In order to create Partial Copy sandboxes, you should first apply a sandbox template during the time of creation.
At the baseline, a partial copy sandbox is the metadata copy of production organization, which is the same as a developer or developer pro sandbox. However, adding to it, it has a sandbox copy engine which can sample the data from production orgs based on which a sandbox template is defined. For every selected object in the sandbox template, the copy engine can sample up to about 10000 records. Say for example, while using a template which includes Accounts for creation of Partial Copy sandbox, you can find that about 10,000 Account records get copies to the newly created sandbox; however, there is is no extra-record copies.
Testing environment staging
If you have to customize orgs at various staging environments in order to test the changes whereas the production is not getting affected or the production orgs. It is also possible to maintain orgs where users can easily log in as well as test features of the apps developed before getting into production. At times, the need will be to do the login to any of the Salesforce orgs for development or training by simply mirroring the production org, which may be enabled by the sandboxes.
Along with this, Salesforce also offers different deployment tools too to achieve the following.
- Isolation of the development environment from the production environment unless it is matured for deployment.
- To test the changes made against various copies of production data and the users.
- Offer an optimized environment for training.
- Effectively coordinating the individual changes in the deployment to the production of the process.
Even if an admin adds or changes the org features or if a developer changes the codes prepared, it is important to use the right tools in the right environment in order to build and deploy the production orgs effectively. In order to get a typical overview of the development and testing process as well as to get appropriate recommendations, you may also explore the app development lifecycle module on the Salesforce Trailheads.
As we already know, Sandboxes exists as standalone entities and the actions you perform on these may not reflect on production orgs. So, you can easily create different sandbox environments independently for each orgs based on the varying needs of orgs in terms of storage, configuration, and also refreshing the frequencies.
Various considerations to make in this process are:
IDs and servers
You can see that the Sandbox orgs and Production orgs may have unique IDs. Copy engines may create the orgs against creating and refresh requests. So, the org IDs of a particular sandbox may change each time when you try to refresh the sandbox. Salesforce Dx may typically insert a new value each time at all places where an org ID is used as the text values and metadata.
In order to identify org ID which you are logged in, you can access the Setup and Company Info and click on the Quick Find button to get the corresponding info. Any of the available script or process as Web-to-Lead or other test scripts depending on the hard-coded org ID may use the updated ID for the Sandbox. Also, when you try to deploy the Production Org changes, all the processes and scripts may need to be updated with the Production Org ID.
To conclude, Salesforce creates Sandbox Orgs during different instances. Wherever you create a new org or trying to refresh an existing one, Salesforce may choose an instance for the sandbox which appears with unique URLs for each individual instance.