Sandboxes and change sets
Sandboxes and change sets for testing new implementations
A sandbox is a copy of a Medallia Experience Cloud production instance that mimics the functionality of that instance. Each sandbox is a new instance, and includes a portion of data and the full configuration of its production instance. This enables you to develop and test surveys, reports, integrations, and so on safely before promoting those changes to production.
A change set is a collection of configuration entities (such as fields, surveys, email templates, and so on), grouped for the purpose of copying those changes from one Experience Cloud instance to another. For example, you might use change sets to copy survey modifications from a test sandbox to your production instance.
For information about managing sandboxes in Medallia Admin Suite, see Sandboxes. For information about managing change sets, see Change sets.
Accessing sandboxes and change sets
To use Sandboxes and Change sets, roles need one or more of the Sandboxes permissions listed in Administrative permissions. For more information, see:
To access Sandboxes and Change sets, click the Sandboxes tile under the Administration Tools section and select an option:
Example workflows
While change sets enable you to replicate configurations between instances, the way to manage the workflow of this functionality depends on the administration needs of your company. This section describes common workflows involving one or more sandboxes and your production instance.
While these workflows present scenarios that use sandboxes to make and test configuration changes, Experience Cloud does allow you to make configuration changes directly on the production instance. This can result in the production instance having updates that the sandboxes do not have.
Basic workflow
Whether your company has one or several Experience Cloud administrators, if you are making simple or infrequent changes you might need a workflow that involves only a single development sandbox for your production instance.
With this workflow, all new configurations are made and tested on the sandbox. When testing is completed, an administrator creates an outgoing change set containing the new and changed configuration entities, submits that change set to the production instance, and then deploys that change set on the production instance.
Development and test workflow
If your company has multiple administrators, consider a workflow that involves multiple development sandboxes and a testing sandbox.
With this workflow, several administrators can work simultaneously on configurations for different parts of Experience Cloud. For example, if you use multiple survey programs, you might reserve a sandbox for each program. Alternatively, you might reserve one sandbox for survey changes, another for reporting changes, and so on. As administrators complete their work, they submit change sets to the testing sandbox. When all changes on the test sandbox have been tested, an administrator creates a change set to copy all of the changes from the test sandbox to the production instance.
Staging workflow
Larger companies, especially multi-market companies, might consider a modified development-and-test workflow that includes a staging sandbox.
This workflow operates much like the previous workflow, but instead of copying configuration entities from the testing sandbox to the production instance directly, an administrator tests and approves changes on the testing instance, and then copies them to a staging instance. When your company is ready to deliver the new changes to customers, create a change set copying entities from the staging instance to the production instance. This workflow enables you to delay the deployment of new entities in production, without halting ongoing development work and tests.
