Sandbox UI guide

This document provides steps on how to perform various operations related to sandboxes in the Adobe Experience Platform user interface.

View sandboxes

In the Platform UI, select Sandboxes in the left navigation and then select Browse to open the Sandboxes dashboard. The dashboard lists all available sandboxes for your organization, including their respective types (production or development).


Switch between sandboxes

The sandbox indicator is located in the top header of the Platform UI and displays the title of the sandbox that you are currently in, its region, and its type.


To switch between sandboxes, select the sandbox indicator and select the desired sandbox from the dropdown list.


Once a sandbox is selected, the screen refreshes and updates to the sandbox you selected.


Create a new sandbox create

The creation of a new sandbox requires you to add it to a role in Permissions before you can begin using it. To learn how to provision a sandbox for a role, refer to the managing sandboxes for a role documentation.

Use the following video for a quick overview on how to use Sandboxes in Experience Platform.

In this video, we’re going to talk about sandboxes in Adobe Experience Platform. A sandbox is a virtual partition of a platform instance. Using sandboxes, you can develop, test, and experiment with platform features without affecting your production environment, and run multiple platform-enabled applications in parallel. When you create resources, ingest data, and perform other data operations on platform, all of that activity is contained within a sandbox. When you create additional sandboxes, you’re essentially creating different, separate versions of your platform instance. Each sandbox maintains its own resources, including schemas, datasets, profiles, and more, and actions taken in one sandbox do not affect any other sandboxes. Outside of Experience Platform, support for sandboxes varies across the Experience Cloud ecosystem, such as an Adobe Target or Adobe Audience Manager. For details on how each product supports sandboxes, please refer to the product documentation. There are two kinds of sandboxes in Platform, Production Sandboxes and Development Sandboxes. A Production Sandbox is meant to be used with profiles in your production environment. When you purchase Platform, you have one Production Sandbox, which is the default sandbox for your organization. If needed, you can create additional Production Sandboxes dedicated to distinct lines of business, brands, projects, or regions. However, only one of these Production Sandboxes can be set as the default. Unlike other sandboxes, the Default Production Sandbox cannot be deleted or reset. When using external systems to ingest data into Platform, some applications don’t have a way of deciding or specifying which Platform sandbox to send data to, and therefore can only work with the Default Sandbox as a fallback. By contrast, Development Sandboxes are used exclusively for development and testing with non-production profiles. As new features and campaigns are built and approved, you can merge those changes into other sandboxes. For example, you can merge them with other Development Sandboxes for user acceptance testing and staging, and once that’s complete you can merge them into the Production Sandbox. Using the sandbox tooling feature, developers can easily select which sources, schemas, datasets, identities, audiences, and governance policies that they want to export and include them in a package. This package can then be imported to other sandboxes as needed. Okay, let’s jump into the interface and see how sandboxes are managed in Platform, starting with how to get access to them in the first place. In order to use a sandbox belonging to your organization, you must be granted access to that sandbox by an administrator. This is done through the Permissions tab in Platform, which is only available to system admins or product level admins for Experience Platform. Within this tab, administrators can create roles that grant access to specific feature permissions in Platform along with one or multiple sandboxes. When the admin assigns a user to a role, that user gets access to those features across all sandboxes specified in that role. For more details on roles, please refer to the Access Control Guide in the Platform documentation. Whenever you’re in the Platform interface, you can see which sandbox you’re in via the top navigation up here, including its name and whether it’s a development or production sandbox. Clicking on it, we can easily switch the experience between any sandbox that we’ve been granted access to through permissions, in our case, a production sandbox and a development sandbox. Notice that in production, there are a number of schemas and datasets already defined and in use. Switching to the development sandbox, these are gone, providing a clean slate for us to begin experimenting and testing. Let’s say that we’ve been running a ton of experiments in our development sandbox, and over time it’s gotten bloated with test data and assets. Whether it’s datasets, schema names, segments, and so on, we have plenty of hello worlds here that need to go. We could just methodically delete these unneeded assets one by one, but since we’re working in a development sandbox, we have the option to reset the entire sandbox and start from a clean slate instead. If we’ve been granted sandbox reset permissions through our assigned role, we can go to Sandboxes in the left nav and select the sandbox that we want to reset for the list. After selecting Sandbox Reset, we’re warned that this will delete all user-created resources in the sandbox and that this cannot be undone. To confirm our choice, we’ll need to manually type the name of the sandbox here, and once we hit reset, our sandbox will be returned to its original, pristine state. If we have sandbox administration permissions for platform, we can also use the Sandboxes tab to edit the basic details for a sandbox. If a sandbox is not currently acting as our default production sandbox, and we otherwise don’t need it, we can delete it from here. Finally, let’s take a quick look at how sandboxes work in platform APIs. To send a request to any platform API endpoint, you need to include the name of the sandbox you want the operation to take place in as a header. You can find this name by clicking into the sandbox in the interface and finding it listed in the right rail. Let’s make some calls to the datasets endpoint in the catalog API to show how this works. I’m using Postman here, but you can use whatever method you’re comfortable with for making calls to REST APIs. When we include the name of our development sandbox in our request header, we can see that this returns the list of datasets that are stored in that sandbox, including this test dataset that we made recently here. If we switch the sandbox name to prod and make the call again, we pull up our production datasets instead. No matter what actions you perform across the dozens of available platform API endpoints, every call is made in the context of a single individual sandbox, ensuring that all your sandboxes safely operate in isolation from each other. You should now have a better understanding of how to leverage sandboxes to use, explore, and experiment with platform features without the risk of adversely affecting your production environment. Thanks for watching.

To create a new sandbox, select Create sandbox on the top-right corner of the screen.


The Create sandbox dialog box appears. If you are creating a development sandbox, select Development in the dropdown panel. To create a new production sandbox, select Production.


After selecting the type, provide your sandbox with a name and a title. The title is meant to be human-readable and should be descriptive enough to be easily identifiable. The sandbox name is an all-lowercase identifier for use in API calls and should therefore be unique and concise. The sandbox name must begin with a letter, have a maximum of 256 characters, and consist only of alphanumeric characters and hyphens (-).

When finished, select Create.


Once you have finished creating the sandbox, refresh the page and the new sandbox appears in the Sandboxes dashboard with a status of “Creating”. New sandboxes take approximately 30 seconds to be provisioned by the system, after which their status changes to “Active”.


Reset a sandbox

The following is a list of exceptions that can prevent you from resetting the default production sandbox or a user-created production sandbox:
  • The default production sandbox cannot be reset if the identity graph hosted in the sandbox is also being used by Adobe Analytics for the Cross Device Analytics (CDA) feature.
  • The default production sandbox cannot be reset if the identity graph hosted in the sandbox is also being used by Adobe Audience Manager for the People Based Destinations (PBD).
  • The default production sandbox cannot be reset if it contains data for both CDA and PBD features.
  • A user-created production sandbox that is used for bi-directional segment sharing with Adobe Audience Manager or Audience Core Service can be reset after a warning message.
  • Before initiating a sandbox reset, you will be required to delete your compositions manually to ensure that the associated audience data is cleaned up properly.

Delete audience compositions

Audience composition is currently not integrated with the sandbox reset capability, so audiences will need to be deleted manually prior to performing the sandbox reset.

Select Audiences from the left navigation and then select Compositions.

The Compositions tab in the Audiences workspace.

Next, select the ellipsis (...) next to the first audience, then select Delete.

The audience menu highlighting the Delete option.

A confirmation of successful deletion is displayed and you are returned to the Compositions tab.

Repeat the above steps with all your compositions. This will delete all audiences from the audience inventory. Once all audiences have been removed, you can continue to reset the sandbox.

Resetting a sandbox

Resetting a production or development sandbox deletes all resources associated with that sandbox (schemas, datasets, and so on), while maintaining the sandbox’s name and associated permissions. This “clean” sandbox continues to be available under the same name for users that have access to it.

Select the sandbox you want to reset from the list of sandboxes. In the right-navigation panel that appears, select Sandbox reset.


A dialog box appears prompting you to confirm your choice. Select Continue to proceed.


In the final confirmation window, enter the name of the sandbox in the dialog box and select Reset.


Delete a sandbox

You cannot delete the default production sandbox. However, any user-created production sandbox that is used for bi-directional segment sharing with Audience Manager or Audience Core Service can be deleted after a warning message.

Deleting a production or development sandbox permanently removes all resources associated with that sandbox, including permissions.

Select the sandbox you want to delete from the list of sandboxes. In the right-navigation panel that appears, select Delete.


A dialog box appears prompting you to confirm your choice. Select Continue to proceed.


In the final confirmation window, enter the name of the sandbox in the dialog box and select Continue.


Next steps

This document demonstrated how to manage sandboxes within the Experience Platform UI. For information on how to manage sandboxes using the Sandbox API, see the sandbox developer guide.