About sandboxes¶
A sandbox is a copy of your production tenant in which you can safely make configuration changes, validate the results, and then safely promote those changes to production.
Allow sandbox administration¶
The Allow sandbox administration policy allows full access to all sandboxes in a tenant, including the ability view details for any sandbox, access any sandbox, promote changes from any sandbox to production, and delete any sandbox.
Assign this policy to one (or more) users who are assigned the DataGrid Operator policy so those users can manage all sandboxes that exist for your production tenant.
Important
A user who is assigned to the DataGrid Operator policy can create a sandbox, and then open that sandbox to make configuration changes. While working in a sandbox, a DataGrid Operator is assigned the DataGrid Administrator policy, which allows a user to have full access to the configuration state of the sandbox.
A user must be assigned the Allow sandbox administration policy option to do any of the following:
View details for all sandboxes
Access any sandbox
Promote changes from a sandbox to production.
Delete a sandbox from the Users and Activity page or by selecting the Promote and delete sandbox option while promoting changes from a sandbox.
About sandbox workflows¶
Amperity recommends using a sandbox to make all configuration state changes to your brand’s production tenant.
A sandbox is a copy of your production tenant in which you can safely make configuration changes, validate the results of those changes, and then from which you can safely promote those changes to production.
What isn’t copied to a sandbox?
Versioned table histories A sandbox is a copy of your production tenant. A database in a sandbox needs to be run before the tables in that database will contain data. The initial database run in the sandbox is different from the database run in your production tenant and, as such, starts a new version history for each table in the sandbox.
All sandbox workflows follow the same pattern: create a sandbox, make iterative changes in the sandbox, review and validate all changes, promote validated changes to production.
|
Sandboxes are created from the Users & Admin page. Find the Sandboxes section, and then click Create sandbox. 
To access a sandbox, from the list of sandboxes, select the icon, and then from the list of options select Access sandbox. 
Important Data is not moved between production and a sandbox. Configuration state is copied from production, and then applied to the sandbox. Tip If a sandbox is created while a Stitch run is in progress, wait for the Stitch run to finish in production before running the database in the sandbox. This will allow the database in the sandbox to use the most recent Stitch outputs in production for the initial database refresh in the sandbox. |
|
Sandbox configuration works the same way as it does in production with all of the same features and functionality. The main difference is that users in a sandbox are assigned the DataGrid Administrator policy, which gives them full access to the configuration state within the sandbox. When you access a sandbox, it’ll look much the same as production, but with a different color scheme. 
Validate all configuration changes Sandbox-specific notifications are built into the pages to help you identify the current configuration state of the sandbox as it relates to the configuration state in production. These appear near the top of each page. A notification is shown when action is required to synchronize the configuration states between a sandbox and production. For example: 
after which you can review the details for each update that may be available. 
A list of changes will appear under the Added, Changed, or Removed sections. Click the name of the update to learn more about the differences between the configuration states of your sandbox and production. Review the list of Added, Changed, and/or Removed configuration state changes. Click the name of the added, changed, or removed object to review the details for the configuration state change. Resolve validation issues, as necessary. 
|
|
When the sandbox is ready to be promoted, click Promote. Enter a merge message for this set of configuration state changes. 
|
Best practices¶
Amperity recommends the following patterns when working with sandboxes:
Activate queries¶
Be sure to activate all queries that should be promoted from the sandbox to production. Any query in a draft state is not promoted.
Continuous validation¶
As you make changes within a sandbox, Amperity will continuously run validations against those changes. If an issue is discovered a notification will appear along with a link to learn more about the validation issue and the steps that may be required to resolve it. You should fix validation issues as they arise to keep your sandbox ready to be promoted to production.
Data across environments¶
Data is not moved between your production environment and a sandbox environment. Only the configuration state is copied to the sandbox environment and only changes to the configuration state are copied back to your production environment.
For example, if you use a sandbox to add the components required by a new data source, such as a courier, a feed, along with a custom domain table in which semantic tags are applied, after promoting those changes from a sandbox environment you will need to run the courier to pull the data to your production environment.
Delete sandbox on promote¶
You can automatically delete a sandbox using the Promote and delete sandbox option when promoting changes from a sandbox to production.
Run partial workflows¶
Each workflow should be validated before promoting changes to production using a partial workflow.
A partial workflow pulls data from upstream sources to the sandbox, run Stitch, and then refresh databases.
A partial workflow does not run orchestrations or campaigns. This ensures that data in your sandbox is not inadvertently sent to any downstream workflows.
Short-lived sandboxes¶
A sandbox should be short-lived and should be used to make small, iterative changes within your tenant. After these changes are safely promoted to production, the sandbox should be deleted. Use a sandbox for each iterative change to ensure that you are never making large changes to production.
Examples of small, iterative changes
Each sandbox should exist only to support a specific set of planned configuration state changes.
A new data source in sandbox A
A new destination in sandbox B
Changes to a Profile API endpoint in sandbox C
A set of custom database tables in sandbox D
After these changes are promoted to production, the sandbox should be deleted.
Common activities¶
This section describes tasks related to working with sandboxes in Amperity: