Use sandboxes
- Topics:
- Sandboxes
CREATED FOR:
- Beginner
- Developer
- Admin
Learn how Experience Platform sandboxes provide isolated environments to try out new or existing functionality and work with a “fail fast” approach. Learn how to reset and restart the development environments and use sandboxes with API calls. For more information, please visit the Sandboxes user 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.
Experience Platform
- Platform Tutorials
- Introduction to Platform
- A customer experience powered by Experience Platform
- Behind the scenes: A customer experience powered by Experience Platform
- Experience Platform overview
- Key capabilities
- Platform-based applications
- Integrations with Experience Cloud applications
- Key use cases
- Basic architecture
- User interface
- Roles and project phases
- Introduction to Real-Time CDP
- Getting started: Data Architects and Data Engineers
- Authenticate to Experience Platform APIs
- Import sample data to Experience Platform
- Administration
- AI Assistant
- Audiences and Segmentation
- Introduction to Audience Portal and Composition
- Upload audiences
- Overview of Federated Audience Composition
- Connect and configure Federated Audience Composition
- Create a Federated Audience Composition
- Audience rule builder overview
- Create audiences
- Use time constraints
- Create content-based audiences
- Create conversion audiences
- Create audiences from existing audiences
- Create sequential audiences
- Create dynamic audiences
- Create multi-entity audiences
- Create and activate account audiences (B2B)
- Demo of streaming segmentation
- Evaluate an audience rule
- Create a dataset to export data
- Segment Match connection setup
- Segment Match data governance
- Segment Match configuration flow
- Segment Match pre-share insights
- Segment Match receiving data
- Audit logs
- Data Collection
- Dashboards
- Data Governance
- Data Hygiene
- Data Ingestion
- Overview
- Batch ingestion overview
- Create and populate a dataset
- Delete datasets and batches
- Map a CSV file to XDM
- Sources overview
- Ingest data from Adobe Analytics
- Ingest data from Audience Manager
- Ingest data from cloud storage
- Ingest data from CRM
- Ingest data from databases
- Streaming ingestion overview
- Stream data with HTTP API
- Stream data using Source Connectors
- Web SDK tutorials
- Mobile SDK tutorials
- Data Lifecycle
- Data Science Workspace
- Overview
- Architecture
- Load data in JupyterLab notebooks
- Query and discover data in JupyterLab notebooks
- Exploratory Data Analysis
- Recipes, models, and services overview
- Build a model using the recipe builder template
- Analyze model performance
- Create and publish a trained model (UI)
- Schedule automated training and scoring for a service
- Enrich Real-Time Customer Profiles with machine learning insights
- Package source files into a recipe
- Import a packaged recipe (UI)
- Import a packaged recipe (API)
- Destinations
- Destinations overview
- Connecting to destinations
- Create destinations and activate data
- Activate profiles and segments to a destination
- Configure a dataset export destination
- Integrate with Google Customer Match
- Configure the Azure Blob destination
- Configure the Marketo destination
- Configure file-based cloud storage or email marketing destinations
- Configure a social destination
- Activate through LiveRamp destinations
- Adobe Target and Custom Personalization
- Activate data to non-Adobe applications webinar
- Identities
- Intelligent Services
- Monitoring
- Partner data support
- Profiles
- Understanding Real-Time Customer Profile
- Profile overview diagram
- Bring data into Profile
- Customize profile view details
- View account profiles
- Create merge policies
- Union schemas overview
- Create a computed attribute
- Pseudonymous profile expirations (TTL)
- Delete profiles
- Update a specific attribute using upsert
- Privacy and Security
- Introduction to Privacy Service
- Identity data in Privacy requests
- Privacy JavaScript library
- Privacy labels in Adobe Analytics
- Getting started with the Privacy Service API
- Privacy Service UI
- Privacy Service API
- Subscribe to Privacy Events
- Set up customer-managed keys
- 10 considerations for Responsible Customer Data Management
- Elevating the Marketer’s Role as a Data Steward
- Queries
- Overview
- Query Service UI
- Query Service API
- Explore Data
- Prepare Data
- Adobe Defined Functions
- Data usage patterns
- Run queries
- Generate datasets from query results
- Tableau
- Analyze and visualize data
- Build dashboards using BI tools
- Recharge your customer data
- Connect clients to Query Service
- Validate data in the datalake
- Schemas
- Overview
- Building blocks
- Plan your data model
- Convert your data model to XDM
- Create schemas
- Create schemas for B2B data
- Create classes
- Create field groups
- Create data types
- Configure relationships between schemas
- Use enumerated fields and suggested values
- Copy schemas between sandboxes
- Update schemas
- Create an ad hoc schema
- Sources
- Use Case Playbooks
- Experience Cloud Integrations
- Industry Trends