--- title: "Sandboxes" slug: admin/sandbox url: https://projectri.com/docs/admin/sandbox section: admin audience: admin app_route: "/[slug]/admin/sandbox" permissions: [sandbox.view, sandbox.manage] plan: platform.sandbox mobile: "/admin/sandbox" updated: 2026-09-08 source: Projectri documentation --- # Sandboxes A copy of this workspace that is safe to break — its own address, its own expiry, and an outbox that captures everything it would have sent. ![Sandboxes](https://projectri.com/docs-shots/admin-sandbox.png) ## What it is A sandbox is a separate workspace provisioned as a copy of this one, so that "can we try the new approval rules against our own data first" has an answer that is not "clone the database and hope". It gets its own address, it expires on its own clock, and nothing it does reaches the outside world. ## How to get there **Organization → Sandboxes** in the admin console rail, at `//admin/sandbox`. It sits beside Company and Settings because a sandbox is a copy of the whole workspace, not a resourcing artefact. Seeing the list, the clone history and the captured outbox needs `sandbox.view`. Creating, extending and destroying one needs `sandbox.manage` **and** the `platform.sandbox` plan entitlement. ## How to use it ### Create one 1. Press **New sandbox**. At the cap — **five** at once — the button is disabled and says so, rather than letting you find out from a refusal. 2. Give it a name. 3. Choose **what to copy**: - **Configuration only** — settings, roles and rate cards. No projects, tasks or client records come across. - **Configuration and data** — projects, tasks and time as well. 4. **Replace names and email addresses** is on by default. Turn it off only if the people using the sandbox may already see the real records. With it off and the data mode chosen, the copy carries real client names and real email addresses, and the sentence under the form says so in those words as you change the controls. 5. Set the **lifetime in days**, between 1 and 365. It is destroyed automatically when it runs out. 6. Set the sampling bounds — how many **projects** and how many **months of history** to copy. Only the most recent are taken, so a large workspace still clones quickly. At most 200 projects and 60 months. 7. Create it. The new workspace gets its own slug, of the form `sbx-` followed by a short id, and appears in the list. ### Manage a live one 1. The list shows each sandbox's name, its address, and how long it has left. The days-remaining figure is the server's — nothing on the screen recomputes it against a browser clock that may be an hour out. 2. **Extend** adds days to what is left, not to today. 3. **Destroy** removes it and everything in it. 4. **Captured mail** opens what that sandbox tried to send. ### Read the clone history The history lists every clone attempt in all three states — finished, still running, and failed — with how long it took and which tables carried the most rows. The row is written *before* the copy starts, so a request that died mid-flight leaves evidence. A history of successes would hide exactly the rows somebody came here to find. ### Read the captured outbox A sandbox never sends anything. Every email, push, webhook, chat message, outbound integration call and payment attempt it makes is captured instead, with its recipient and subject. This is the panel that removes the reason anybody would ever turn real sending on to find out whether their rule fired. ## What it affects - **Nothing leaves a sandbox.** The suppression lives inside the dispatch functions themselves — the last code that runs before the network — so a new feature inherits it by construction rather than by remembering. - **There are two layers of that guard.** By workspace, for everything that knows which workspace it is acting for; and by recipient, for the send paths that do not, which catches the call site nobody remembered to update. - **An anonymised clone adds a third layer**: its addresses are on a reserved domain that can never resolve. - **Ids are remapped by value**, including ids buried inside JSON columns like an automation's conditions or a dashboard panel's filter. A rule copied into a sandbox points at the sandbox's own project, not the original. - **The owner is warned before it expires** — seven days out, and one day out — and then it is deleted. A sandbox that vanished mid-test with no notice would teach people to distrust the feature. - **Expiry is the feature.** A sandbox that lived forever would be a second production workspace nobody audits, holding a copy of a client list. ## On mobile `Admin → Sandbox` leads with what is about to expire, shows all three clone states, and puts the captured outbox one tap away. Creating one stays on a laptop — it is a form whose most important element is the sentence saying whether real client names are about to be copied, and that is not a thing to fill in one-handed on a train. ## Limits and gotchas > [!WARNING] > With **Configuration and data** selected and anonymisation switched off, the > sandbox holds real client names and real email addresses. It is a second copy > of that data, in a workspace with its own membership. - Five sandboxes at once. Destroy one to make another. - A failed clone is torn down rather than rolled back — the sandbox workspace is created first and its rows deleted in reverse order on any failure, because a single transaction around a large clone would hold locks on tables production is writing to. - Any one table is capped at 5,000 rows in a clone, after the sampling bounds are applied. That is what makes "the clone finishes" a property of the code rather than of the customer. - Extending is bounded by the same 1-to-365 range. There is no "never expires". - A running clone that never finishes leaves a row in the history saying so; it is not evidence of a sandbox you cannot see. ## Related - [Settings](/docs/admin/settings) — the configuration a sandbox copies. - [Workspaces](/docs/admin/workspaces) — the workspaces inside a company. - [Automation](/docs/admin/automation) — the commonest thing people rehearse in one. - [Data and privacy](/docs/features/data-and-privacy) — where copies of customer data live. ## Related - [Settings](https://projectri.com/docs/admin/settings.md): Branding, region, locale, the working week and storage policy — the tenant preferences that every other screen in Projectri reads. - [Workspaces](https://projectri.com/docs/admin/workspaces.md): The containers projects live in, and what kind of place each one is — the type sets what a new project inherits and whether customers may be let in at all. - [Automation](https://projectri.com/docs/admin/automation.md): Rules that react to what happens in this workspace — a trigger, optional conditions, and an ordered flow of actions, waits and branches. - [Data and privacy](https://projectri.com/docs/features/data-and-privacy.md): Where a workspace's data lives, how long it is kept, how a person gets a copy or has it erased, and why closing an account is not the same as erasure.