As per the development lifecycle guide, the experts recommend that Salesforce sandboxes need to be refreshed periodically to make sure that they have the latest configuration info and data. Refreshing a sandbox is, of course, a necessary thing; however, this guidance leaves us open-ended as to how frequently it should be refreshed. Periodically means once a day or once in a week or once every quarter? However, Salesforce enforces some limits as to how often the sandboxes to be refreshed. Let’s explore.
As we have seen in another article in the series, there are various types of sandboxes on offered by Salesforce. The full Copy sandboxes may contain the production data. Accordingly, there are heavy restrictions also as to how often the developers can refresh those. For the full copy sandboxes, the refresh limits could be once every 29 days. For partial copy sandboxes, which contain only a smaller fraction of the production data, it can be refreshed much more frequently. However, this isn’t something that can be done daily. Usually, partial copy sandboxes are refreshed once every five days.
If full or partial copy sandboxes are deleted, then one may have to wait for another 29 or 5 days, respectively, to create a new one. On the other hand, developers and developer pro versions of sandboxes could be refreshed once a day. Doing so will be useful if you are trying to implement some continuous integration.
Why is the Sandbox refresh necessary?
As we have seen, Salesforce sandboxes are counted as important by many, but in the case of many others, it is an underused asset. Many Salesforce development teams tend to ignore Sandboxes as an unnecessary thing. Even those teams which are utilizing sandboxes effectively tend to neglect the process of refreshing. As there are some limits for the sandbox refreshes, a lot of teams tend to undervalue them or neglect. The limitation of refresh availability actually means that updating sandboxes is not kept at the top of the to-do list, and also the importance of regularly refreshing the sandbox is ignored or forgotten.
At the baseline, refreshing the Salesforce sandbox is all about renewing the development environment irrespective of being Full or Partial Copy sandboxes, which also enables mirror production as simple as possible. While performing sandbox refreshes, data in the sandbox gets pulled out from the production in order to make sandbox closer to perfection as restricted by its type. For example, Partial Copy may not look like the exact copy of production as it has a limit for the number of records it may hold.
Having the most accurate data is essential while developing business applications as it will let you feel confident so that your codes will not change when you break into the production instances. A lot of Salesforce is tied to data as well as testing the features against the most accurate data.
However, sandbox refreshes may also ring down the changes in metadata. This is also crucial to take care of. You not only want the data in the sandbox in order to match the production, but you may also want the metadata to act so. This is also a place where there are many teams, and there are a lot of teams that are out of practice.
You may take the example as of two sandboxes in which the business has featured a request that requires an Apex trigger as well as a custom field to add. Let’s consider those as Sandbox A and Sandbox B. Sandbox A is refreshed from the production. The metadata in Sandbox A is similar to what is there in production. Sandbox B is handled by multiple developers and not refreshed in about a year. This may seem to be extreme; however, it is so common among the Salesforce developers. However, metadata get refreshes to keep the development environment in tune with the production.
When it comes to migrating changes from Sandbox A to the production environment, it will run smoothly during the Salesforce sandbox refresh interval. The primary only difference between the two orgs is the changes that you try to deploy. So, in such a case, there is no danger of overwriting the metadata in production, and also there is no danger or any dependency issues in terms of creating bugs or other types of challenges.
When it comes to Sandbox B, the story is not that simple. Sandbox B, in this case, not just different from the production, but there are many unused classes, fields, and triggers which are not present in production. When we try to test the new features on the sandbox, it may look good without any issues. However, when it comes to deployment, things may change. How can one be sure that the features will not break into production due to any dependency issues?
As described in the above case study, this is one challenge that plays big in the case of enterprise development, where there are many teams that push towards Salesforce continuous integration. Making frequent changes as well as keeping the developers and testers in sync with the production environment will minimize the risks of any bugs and unforeseen issues.
Refreshing a Sandbox
It is so simple to refresh a Salesforce sandbox. Just go to the Setup and choose the Data Management option to see the Sandboxes beneath it. You can see a list of Sandboxes out here. Those Sandboxes which are eligible for refreshment will be having the “Refresh” button next to it. While clicking on this link, you can see the command “Copying” running there. Once the refreshing is finished, Salesforce will send you an email notification.
Once it is completed, then you need to activate the sandbox in order to utilize the changes made. You can see the status as “Replacement ready.” Simply click on the Activate option in order to make the refreshed sandbox available. Once you do this, however, all the data may be lost. You need to consider this fact while doing the refresh as a proper backup of data needed to be taken if there is a risk of data loss.