Training Sandboxes

A training sandbox is a practice copy of DevStride, pre-loaded with the Acme demo dataset, where your team can learn and experiment freely. Nothing done inside a sandbox reaches your real organization: it is a separate organization, with its own data and its own accounts.

Use one for onboarding a new team, rehearsing a process change, or letting someone try a destructive action — reparenting a tree, bulk-editing a board, deleting a workstream — somewhere it does not matter.

Where to find it

Settings → Organization → Training Sandboxes. The page is visible to roles holding the Manage training sandboxes permission (MANAGE_TRAINING_SANDBOXES), which carries access to Settings with it. The Owner has it by virtue of full authority; the default Admin role does not. Grant it deliberately — to the people who should be able to create and destroy sandboxes — by adding the Manage training sandboxes permission to a role (see Roles and Permissions).

Creating a sandbox

Fill in the Create a sandbox form and choose Create sandbox:

• Name — the sandbox's identifier, prefixed with your organization's own name (acme-onboarding).
• Display name — what the sandbox calls itself once you are inside it.
• Reads as "today" — the date the demo dataset is anchored to, so its cycles, due dates, and reports read as current rather than as history.
• Sign-in password — the password every account in the sandbox will use. Choose one you are willing to share with everyone who will train in it.

The build takes a few minutes. You do not need to wait on the page or refresh it — the list updates on its own when the build finishes. While a build is running it counts toward your sandbox limit.

Signing in to a sandbox

This is the step that surprises people. A sandbox does not appear in your organization switcher, and your own account is not a member of it. Each sandbox is built with its own set of accounts, one per permission level, and you enter it by signing out and signing back in as one of them.

Every built sandbox has a How do I sign in? link next to its name. Open it to see that sandbox's usernames — each maps to a different permission level, so you can hand a colleague the one that matches what you want them to practise. The password is the one set when the sandbox was created, or the one set at its last reset.

Dataset freshness

The demo dataset behind sandboxes is refreshed over time, so each sandbox shows how current its copy is:

An older dataset still works perfectly well for training. Reset only when you actually want the newer content, because a reset is destructive.

Resetting and destroying

Both actions erase everything inside the sandbox, and both ask you to type the sandbox's name to confirm. Neither can be undone.

• Reset rebuilds the sandbox from the current demo dataset. You pick a new date for it to read as "today" and a new sign-in password; every account is re-created with that password. Use it to clear out a finished training session, or to pick up a newer dataset.
• Destroy removes the sandbox permanently and frees its slot.

Limits

Your organization can hold a limited number of sandboxes at once, and builds still in progress count toward it. The page tells you the limit when you reach it; destroy a sandbox you no longer need to free a slot.