Sandbox UI guide

Transcript

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.