Partial Copy and Full sandboxes require an additional license to be purchased (contact your Salesforce account manager for more information).

There is no mandatory sandbox configuration setup, but let's have a look at what we can design.

Take a look at the following sandbox architecture, which can be adapted to most projects:

In the preceding diagram, Production is the only organization that is not a sandbox.

Dev 1, Dev 2, and Dev N are part of the Developer (Dev) sandbox and have been assigned to the three developers that are implementing the following project: due to the kind of job developers do, these sandboxes are full production metadata copies, and no data is received from production, so they are free to mess with the dataset.

Once each developer has a stable code base, the changes are released into Integration, which is a Developer Pro sandbox, where everything is tested internally in your team to match the requirements.

If legacy systems have a development environment, you can use this sandbox to test the implementation against external systems. In this case, they usually send mock data, so they are not the proper place to validate external integrations, but from here, you can see whether the code/configurations are running as expected. This place is, in fact, the sandbox where the code base is validated with automated testing (UI or backend testing using Apex test suites).

The Integration sandbox is also the place where developers bring back their colleagues' changes to their own Developer sandbox.

Once the internal testing has been validated, changes are brought to the UAT (or testing) sandbox. This is typically a Full sandbox, but even a Partial Copy could be a good fit. The business guys execute their user acceptance tests and validate legacy integrations.

Once everything is OK, changes are deployed to Staging. This should be a Full sandbox because this is the last place where you can test with actual production data. This place is optimal for bug testing after a production issue.

Finally, the Training organization is used to train your users with these new changes. This is typically a Partial Copy sandbox.

Remember that you can ask Salesforce support for a sandbox license when needed for a limited amount of time. This way, you can dispose of multiple instances of Partial Copy or Full sandboxes so that you can support your projects better.

If your company/customer needs a multi-project environment, you can set up a unique Staging instance, which will collect all the developments and use separate Dev-Integration-UAT branches for each project.

When triggering the creation/refresh of a sandbox, you can select an Apex class to be run after the copy has completed. Use this method if you want to create some basic records for your organization (for example, a base dataset for Developer/Developer Pro organizations).

One additional option when handling a sandbox is cloning. You can clone a given sandbox into a new sandbox of the same license type (for example, a Full Copy must be copied into another Full Copy). Cloned sandboxes can be refreshed as well, and they are aligned with their source sandbox.

Remember that when a sandbox is created, usernames are modified and the .Sandbox-name suffix is appended (passwords and security tokens remain the same). This means that if a user has a username of [email protected] in the new Sandbox called UAT, you would log in with [email protected].uat.

Even users' email addresses are changed by appending the .invalid suffix, so no automatic notification is sent after the sandbox is activated. You need to manually change user emails to enable notification. As we discussed in the previous chapter, Email Deliverability is also set to System Email Only for the same reason.

Plan your sandbox refresh strategy while taking the following into account:

• Full/partial copy refresh/creation can take days to complete.
• A sandbox is not a copy at a given time; production data and configuration data can change during the copy, so some records may be inconsistent.