AWRA OpsHub Search
Security · Sandbox & recovery

Try the change somewhere safe. Prove the backup comes back.

A sandbox workspace holds a copy of your roles, approval rules and procurement and AI settings, none of your records, and sends no email — so a new approval chain or budget block gets tried before it reaches real people. Behind it, AWRA restores its own newest database backup into a separate database on a schedule, and times it.

Start free How a restore drill is judged
Sandbox workspace — yours. Created from Settings by an administrator, one per workspace. Restore drills — ours. A control on the AWRA service and its backups, run by whoever operates the deployment.
Sandbox workspace

A copy of how you are set up, and nothing you have recorded.

The sandbox is a separate workspace linked to yours. It starts with your configuration so a rule behaves the way it would for real, and it starts empty of records so nothing tried there can be mistaken for the books.

Copied in

  • Roles and their permissions, under the same names.
  • Approval rules and their steps. A step that names a person becomes an Admin step, because people are not copied. A rule limited to a department applies to every department in the sandbox.
  • Procurement defaults, including budget control, so a warn-or-block setting can be tried before it holds up real spend.
  • AI settings, including the switches that stop features sending anything to a third-party provider.

Left behind

  • Your records — items, vendors, customers and documents.
  • Your people and departments. The only people in a sandbox are the administrators who step in.
  • Integrations, API keys and audit streaming, so nothing in the sandbox reaches an outside system through them.
  • Changes made inside it. Nothing copies back; once a rule works there, you set it up the same way in your real workspace.
From Settings → Security & Devices → Sandbox

Create it, step in, try it, throw it away.

Create

An administrator with the edit-settings permission clicks Create sandbox. Each workspace has one at a time, and a sandbox cannot have a sandbox of its own.

Step in

Open sandbox swaps your session to your own sandbox user, an Admin there. A banner on every page says you are in the sandbox, with Back to my workspace beside it.

Try it with colleagues

Each administrator who steps in gets their own sandbox person, so one can raise a request and another sign it — which a rule that blocks self-approval needs.

Rebuild or discard

Rebuild from current setup throws the sandbox away and makes a fresh copy of today’s configuration. Discard removes it and everything tried in it.

Why it is safe to hand to an administrator

The properties that keep a test a test.

Nobody signs in to it

Sandbox users have an unusable password and an address on a reserved domain that can never receive a sign-in link. The only way in is stepping in from your own session.

Out only to who came in

Back to my workspace returns the session to the person who stepped in, and only from the sandbox of their own workspace. Stepping in while impersonating someone is refused.

It emails nobody

Two checks hold mail back: one on the workspace a message is sent from, one on the address it is sent to — so a reminder queued without anyone signed in is caught too. Your real workspace keeps sending as normal.

Only a sandbox can be discarded

Discard deletes a workspace only when it is marked as the sandbox of yours, and refuses anything else. Your real workspace is never on the end of that button.

Written to your audit log

Creating, stepping into and discarding the sandbox are recorded in your workspace’s audit log, with who did it and which sandbox.

Visible from the app’s API

The mobile API reports whether a workspace has a sandbox and what it copies. Creating and stepping in happen on the web.

Restore drills

A backup nobody has restored is a hope, not a backup.

So AWRA restores one. A drill takes the newest database backup, loads it into a separate scratch database, times the restore, checks what came back against the live database, records the result and empties the scratch database again.

This is how we test our backups, not a workspace setting. Drills run on the AWRA service, and their results are visible to the system owner, on a restore-drills page and a card on the service-health screen. Drills are off until the deployment names a scratch database and switches them on; once on, one runs every Sunday at 03:40, and the operator can queue one on demand. If you are reviewing us, ask for the drill record.

What makes a drill pass

The import exits cleanly; organizations, users, roles, permissions and migrations come back and are not empty; the backup holds at least 90% of the live tables, so a dump cut short by a full disk fails; and the restore finishes within the recovery time objective — 60 minutes unless the deployment sets another.

The two numbers it keeps

Recovery time is how long the restore took. Recovery point is how old the backup was when the drill started — how much work a restore at that moment would lose. Row counts for items, customers, vendors, purchase orders, invoices and audit entries sit beside the live counts.

It cannot restore over live data

The drill refuses to run if the scratch database it was given is the live one. A failed drill is recorded as failed with the reason, and the service-health card says so — as it does when the last pass is more than a week old.

Sandbox workspace and restore drills — what ships today, and what we can add

What AWRA OpsHub does today

  • One sandbox per workspace, created, rebuilt and discarded from Settings by anyone holding the edit-settings permission.
  • A copy of your configuration: roles and their permissions, approval rules with named-person steps turned into Admin steps, procurement defaults including budget control, and AI settings.
  • None of your records, people, departments, integrations, API keys or audit streaming carried across.
  • Stepping in from your own session as a per-person sandbox Admin, with a banner on every page and a way back only to the person who stepped in.
  • Email held back from anything sent inside the sandbox or addressed to a sandbox user.
  • Audit entries in your workspace when the sandbox is created, entered and discarded.
  • A read-only sandbox status over the mobile app’s API.
  • Weekly restore drills of the AWRA database backup into a separate scratch database, with a pass or fail, recovery time, backup age and table checks recorded for the system owner.

More we can add to your workspace

  • Promote to live: copying a rule or role that worked in the sandbox back into your real workspace in one step.
  • Sample or masked records in the sandbox, so a stock or payroll change can be tried against realistic data.
  • More of your setup copied in, such as custom fields, workflows, notification settings and inventory defaults.
  • An outbox in the sandbox listing the emails it held back, so you can read what real people would have received.
  • Creating and stepping into the sandbox from the mobile app.
  • Drill results published to customers, such as the last pass date and recovery time on the trust centre.
  • Restore drills for stored files and attachments, alongside the database drill.
  • An alert to the operator when a drill fails, beyond the service-health card.

Where we point you to a specialist

  • We will not let a sandbox email your suppliers, customers or staff. Mail from it is cancelled, not delayed.
  • We will not copy anything from a sandbox into your real workspace on our own. A change goes live when someone sets it up there.
  • We will not restore a drill over the live database. The drill refuses a scratch database that is the live one.
  • We will not quote a recovery figure we have not measured. The numbers we give a reviewer come from the drill record.

Promote to live and sample records in the sandbox are the two items in that middle column most organizations ask for first. Tell us which changes you want to rehearse and we will come back with a written spec, a timeline and a price.

Around the sandbox

What you would try in it, and the controls beside it.

Approval rules and delegationChains by amount and department — the first thing most people rehearse. Budget controlsWarn or block spend past what is left, copied into the sandbox with your procurement defaults. AI data controlsThe AI switches the sandbox copies, and the usage log beside them. Enterprise governanceRoles, delegation and the controls a larger organization reviews. Audit log streamingStream your workspace’s audit log, where sandbox activity is recorded, to a SIEM. Security operationsIP rules, device trust, MFA and the audit trail in one layer.

Frequently asked questions

What is copied into the sandbox?
Your roles and their permissions, your approval rules, your procurement defaults including budget control, and your AI settings. A rule step that names a person becomes an Admin step, because people are not copied, and a rule limited to a department applies to every department in the sandbox.
Does the sandbox contain our real records?
No. Items, vendors, customers, documents, people and departments stay in your real workspace, as do integrations, API keys and audit streaming. The sandbox starts with your configuration and no records.
Can the sandbox send email to our suppliers or staff?
No. Any email sent while the sandbox is the current workspace, or addressed to a sandbox user, is cancelled before it leaves. Your real workspace keeps sending as normal.
Who can create and enter the sandbox?
Anyone holding the edit-settings permission can create, open, rebuild and discard it; the view-settings permission shows the Sandbox page. Nobody signs in to a sandbox directly: you step in from your own session as your own sandbox Admin, and step back out to yourself.
Do changes made in the sandbox copy back to our workspace?
No. Once a rule or role works in the sandbox, set it up the same way in your real workspace. Rebuild from current setup gives you a fresh copy of today’s configuration after you have.
What is a restore drill?
A control on the AWRA service itself. It restores the newest database backup into a separate scratch database, times it, checks that the core tables came back and that at least 90% of the live tables are present, records the recovery time and the backup’s age, and empties the scratch database again. Once switched on for a deployment it runs weekly, on Sunday at 03:40.
Can our workspace see the restore drill results?
The results page and the service-health card are visible to the system owner only. If you are reviewing AWRA for security or continuity, ask us for the drill record. Separately from our backups, an administrator can export your organization’s data at any time.

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center