Training Sandboxes

A training sandbox is a separate practice organization, pre-loaded with the Acme demo dataset, where your team can learn and experiment freely. Nothing done inside it reaches your real organization. It is not a copy of your own data: every sandbox starts from the same demo dataset, with its own demo users and sign-in accounts.

Use one to onboard a new team, rehearse a process change, or let someone try something destructive (reparenting a tree, bulk-editing a board, deleting a workstream) where it does not matter.

Where to find it

Configure Settings → Admin → Training Sandboxes. The page opens with a Start here: the training guide link to the Training Sandbox Guide, a follow-along session for every practice account. The page needs the Manage training sandboxes permission, which brings Settings access with it. The default Owner and Admin roles have it; grant the Manage training sandboxes template to any custom role that should create and destroy sandboxes (see Roles & Permissions).

Creating a sandbox

Fill in Create a sandbox and click Create sandbox:

The build usually takes a few minutes. You do not need to stay on the page; Your sandboxes updates on its own when the build finishes, and a build in progress counts toward your limit while it runs.

When the build finishes, your organization's Owners and everyone with the Manage training sandboxes permission get an email and an in-app notification saying the sandbox is ready. It carries the sandbox's sign-in link, its practice usernames and a link to the training guide. It never contains the password; it reminds you that the password is the one set when the sandbox was created or last reset. The same notice goes out after a reset, and when DevStride support hands a sandbox to your organization. A build that fails sends nothing.

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 six accounts, one per permission level, and you enter it by signing out and signing back in as one of them.

Once a sandbox is built, its row lists its practice usernames together with a sign-in link; click Copy sign-in link to share it with trainees. The link opens the DevStride sign-in page with an info icon beside the username field: click it to see the sandbox's practice usernames, and pick one to fill the field. The link never carries the password. The usernames follow the pattern acme.<sandbox-name>.<level> with the levels owner, admin, scrummaster, rte, member and viewer, so you can hand a colleague the one that matches what they should practise. The password is the one you set when you created the sandbox, or at its last reset. Signing in takes you straight into the sandbox; there is no email code to confirm, because the sandbox accounts have practice addresses that receive no mail. For the same reason, a sandbox account's email address cannot be changed.

To run a training session once you are signed in, follow the Training Sandbox Guide: a walkthrough with exercises for each of these accounts.

Signing in to the sandbox's customer portal

Each sandbox has its own Service Desk customer portal. To practise from the customer's side, the person who created or last reset the sandbox can sign in to it as Lena Ortiz, a seeded customer at Globex:

1. Under the sandbox's usernames on the Training Sandboxes page, follow the link to that sandbox's Globex portal. Only the person who created or last reset the sandbox sees it.
2. On the portal, enter your own email address and follow the sign-in link that is emailed to you. You are signed in as Lena Ortiz, with her tickets and her company's shared tickets.

This works only for the account that created or reset the sandbox, and only when that account's email address is verified. Every other seeded customer has an address that receives no mail. If DevStride support hands the sandbox to a different owner at your request, Lena goes back to a placeholder address and any unused portal sign-in links stop working, so the previous owner's address receives nothing further.

Dataset freshness

The demo dataset is refreshed over time, and 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 neither can be undone. Each opens a dialog that asks you to type the sandbox's name to confirm.

• Reset rebuilds the sandbox from the current demo dataset. In the dialog you also choose a new Reads as "today" date and a New sign-in password (at least 4 characters); 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, including any files imported into it, and frees its slot.

A reset or destroy also removes the report exports and Time Allocation Matrix files created inside the sandbox.

The dialog stays open, with a loading overlay, until DevStride accepts the request. The sandbox's row then shows Resetting… or Being destroyed… with a loader until the work finishes, and Reset and Destroy are unavailable on that row in the meantime.

While a sandbox is being torn down its sign-in accounts can no longer be relied on. If a teardown fails to complete, the row says so; contact DevStride support, since an interrupted delete or reset can hold a lock on the sandbox for several hours.

Limits and lifetime

An organization can hold five sandboxes at once, counting builds in progress. When you reach the limit the page tells you; destroy one you no longer need to free a slot.

Idle sandboxes are deleted, with warning

A sandbox nobody uses for 14 days is deleted 7 days later unless someone uses it or keeps it. Signing in to the sandbox, or opening it, counts as use.

• Day 14: the first warning. Your organization's Owners and everyone with Manage training sandboxes get an email and an in-app notification. It says the sandbox has not been used for 14 days and gives the date it will be deleted. That date is given in UTC, so the notice also names the last day you can safely use it, since in the Americas the deletion runs the evening before.
• Every day after that: one reminder, saying how many days are left.
• Every notice gives the same two choices:
  • Keep it: one click from the email, or sign in to the sandbox and open it. Either restarts the 14-day clock and stops the reminders.
  • Delete it now: on the Training Sandboxes page, choose Destroy and type the sandbox's name to confirm.
• If nothing is done, the sandbox and everything inside it is deleted on that date. It cannot be undone.

Each row on the Training Sandboxes page shows where the sandbox stands:

Keep this sandbox needs no typed confirmation, because keeping is harmless. The page then tells you the earliest date the sandbox could next be deleted for inactivity. The Keep it link in a reminder email opens this page with that sandbox highlighted. Keep is refused while the sandbox is being built, reset or deleted, and once its automatic deletion has started.