Overview of Sandboxes

You use sandboxes to make application changes and test them without impacting other users in the environment. Wherever possible, make changes to the application in a sandbox rather than making direct changes in the mainline environment.

Sandboxes isolate untested configuration changes from the mainline environment. So you can test your changes in the sandbox and then publish it to make your changes available in the mainline metadata or other sandboxes after they're refreshed. After you publish, end users can see your changes after they sign out and sign back in.

Why You Need Sandboxes

Today's business landscape is quite dynamic. Companies are expected to respond quickly to address both customer and market needs. So multiple teams need to make application changes at the same time while sharing the same data model and configuration starting point. But you may get conflicts between teams working that way. To avoid such conflicts, sandboxes come in handy.

Here are a few things you can do using sandboxes:

• Select the configuration tools to enable for your sandboxes while creating them. Since you enable all configuration tools in the same way using the Sandboxes UI, you get a consistent sandbox experience across tools.

• Restrict access to various sandbox activities for users. For example, you can specify these access rights for your sandboxes:

  • Full access

  • Edit and preview access

  • View only access

• View just your application changes without having other context layers hide your content.

• Test your changes in a preview mode that shows you exactly how your application changes would appear in a published sandbox.

• Refresh and merge sandboxes with latest changes in mainline metadata from other published sandboxes. After merging all changes, you can publish your sandbox.

• If you register your target environment in your source environment, you can do these additional migration tasks using the Migration UI:

  • Migrate your changes from the test environment to the target environment without manually downloading and uploading the configuration set file.

  • Move only new changes from the source environment to the target environment.

Sandbox Usage

You typically use sandboxes for either of these purposes:

• Test-Only: You can make application changes using test-only sandboxes, which you don't want to publish to the mainline code.

• Publish: Once satisfied with the application changes made in the test-only sandbox, you can replicate these changes in a sandbox that you want to publish. And then publish your changes to the mainline code. This sandbox type is also known as the integration sandbox, because teams working in parallel use this sandbox as the final staging point before publication to the mainline code.

Note:

Before each patch or upgrade, publish or delete your sandboxes. If you haven't yet completed your work, restart with a new sandbox.