A sandbox refresh (or clone) replaces a sandbox instance's data with a copy of another instance, usually production. Refreshes are performed by Administrate on request. Deciding a few things up front makes the request unambiguous and avoids surprises afterwards.
Decide before you request
- Source and destination. Confirm exactly which instance is copied from and which is overwritten. The destination's existing data is replaced.
- Anonymization. By default, personal data in the copy is anonymized. If you need real names and addresses for testing, say so explicitly — and consider whether your data-protection obligations allow it.
- DMS files. Copying the Document Management System's files is a separate step from copying the database. If your testing needs the actual documents (certificate backgrounds, attachments, portal images), request the DMS copy as well; otherwise document references in the sandbox may point at files that are not there.
- Email override address. Supply the single address that should receive every message the sandbox generates. All outbound email is redirected to this address so that triggers and workflows can run in the sandbox without contacting real learners.
- Communication triggers. Decide which triggers should be active in the sandbox after the refresh, and which should stay disabled or in manual mode.
Validate after completion
Before starting your testing, check the refreshed sandbox:
- Spot-check representative data — accounts, contacts, events and financial records.
- Open documents in the DMS if a file copy was requested.
- Review trigger states and confirm the email override is in effect by sending a test communication and checking it arrives at the override address only.
- Check integrations: sandbox copies of production configuration can point at live external systems (payment providers, calendars, webhooks), which you may need to disconnect or repoint.