Understanding test mode and live mode
Last updated: August 24, 2026
Every Onboarded organization has two workspaces: live mode and test mode. They share your team and your forms. Almost everything else has to be built in each mode separately.
What it is
Test mode and live mode aren't a setting applied to one set of data. They're two separate accounts that sit under the same organization, created together the day your organization was set up. Live mode holds your real hires, real tasks, and real integrations. Test mode is the sandbox beside it.
You move between them with the Test mode toggle in the organization selector at the top of the dashboard sidebar. It turns amber when test mode is on. There's no second login and no separate URL — the toggle swaps which of your two accounts you're looking at.
If you remember nothing else: test mode is a second workspace.
Why it matters
Most configuration in Onboarded reaches a real person. A policy assigns real tasks, an automation sends a real email, an integration writes back to a real ATS record. Test mode is where you prove a flow works before any of that lands on a candidate.
Reach for test mode when:
You're standing up a new integration and want to create employees, placements, and tasks freely while you iterate.
You're validating a new form or policy end to end — assigned to someone, filled out, PDF generated — rather than through preview alone.
You're training people on the platform and don't want practice records mixed into production.
You're on a trial organization. Trials run in test mode only until they're upgraded, and the toggle is locked.
Stay in live mode for everything real: actual hires, actual compliance records, and any configuration you've already validated.
How it works
What's shared between modes
Anything that belongs to the organization is shared by both modes. Anything that belongs to an account exists separately in each one — build it in test mode and live mode still doesn't have it.
Surface | Scope | What that means for you |
|---|---|---|
Users, roles, and permission groups | Shared | One login and one set of permissions covers both modes. |
Organization details, verified domains, dashboard branding | Shared | Set once, applies everywhere. |
Tags, form languages, custom attribute definitions | Shared | The definitions are shared. The values recorded against a candidate are not — those belong to whichever mode created the record. |
Forms, form versions, and version history | Shared, deployed per mode | One form, one version number. Each version is deployed to test mode and live mode as two separate actions. |
Policies | Per mode | Build in one mode, then copy to the other. Nothing crosses automatically. |
Automations | Per mode | Same as policies — copy them across deliberately. |
Integrations | Per mode | An integration installed in test mode is not installed in live mode. You install and authenticate it again on the other side. |
API tokens | Per mode | Tokens carry an |
Webhooks | Per mode | Endpoints and subscriptions are registered separately in each mode. |
Themes | Per mode | A theme built in test mode won't style your live candidate experience. |
Custom views | Per mode | Rebuild the view on the other side once you've settled on the columns and filters. |
Candidates, employers, clients, jobs, placements, tasks | Per mode | A record created in test mode is only visible in test mode. This is the most common “where did my data go?” moment — check the toggle first. |
Forms behave differently from everything else
A form is authored once for the whole organization, so both modes look at the same form and the same version numbers. What differs is deployment.
Publishing a version is a single, organization-wide event. Deploying it is per mode, and you deploy from inside the mode you're targeting: the button on the version card reads Deploy (Test Mode) while test mode is on and Deploy (Live Mode) while it's off. A version that's published but not yet deployed to the mode you're in shows as Deployable (Read-only); once deployed it reads Deployed (Read-only).
That's what makes the build-in-test-then-release pattern work. Deploy version 1.2.0 to test mode, run it against sandbox records, make new drafts until it's right, then deploy the version you settled on to live mode. Live mode keeps serving whatever was already deployed there until you do. Deploying is one-way — the confirmation says the action can't be undone — so the way to back out is to deploy a different version, not to undeploy.
Deploying also decides what happens to tasks already in flight, and that choice only touches the mode you're in. Upgrading tasks in test mode never reaches a live-mode task.
Copying policies and automations between modes
Policies and automations don't deploy. They get copied. Open a policy and you'll see a Copy to Live Mode button in the header when you're in test mode, or Copy to Test Mode when you're in live mode. For an automation the same action sits in the More actions menu in the automation editor. It works in both directions — the destination is always the mode you're not currently in.
A copied policy arrives with its rules, its per-form overrides, its tags, and its current enabled status. A copied automation always arrives as an unpublished draft, so you review and publish it on the other side before it can run.
The copy is a snapshot, not a link. Editing the original afterward changes nothing on the copy, and Onboarded won't let you copy the same item across a second time — the button greys out with This policy already exists in Live Mode. To push a revision through, delete or rename the copy on the destination side first, then copy again. For that reason, pick one mode as the place you author a given policy rather than editing both.
Two more limits. You can't copy a copy, so promotion is one hop rather than a chain. And rules pointing at a specific employer, client, or job carry over as written — those records exist per mode, so the reference won't resolve on the other side. Onboarded names the facts to review right after the copy; open the copied policy and re-select them. Policies pushed to you by a platform provider can't be copied at all — the provider controls whether they apply in each mode.
Test mode separates your records. It doesn't intercept your integration interactions.
Onboarded doesn't simulate outbound activity in test mode. If an automation is configured there, it sends a real email or text. If an integration is installed there with production credentials, it submits a real background check, a real E-Verify case, or a real ATS/HRIS writeback. Install each integration in test mode against your vendor's sandbox or test credentials, and confirm what a test-mode automation is set to send before you trigger it.
Example
Take a staffing account bringing a new client onto Onboarded. The client needs a safety quiz, a direct deposit form, and a background check, and the account already runs eleven other clients in live mode.
The HR Engineer publishes both forms and deploys them to test mode. There she installs the background check integration a second time — this time with the vendor's sandbox key — and copies the account's standard offer-letter policy over from live mode. Then she creates a placement against a sandbox employee and walks the whole sequence, watching the PDF generate and the webhook fire.
Two rounds of feedback later, she flips test mode off and deploys the final versions to live mode. She builds the client-specific policy directly in live mode, because a rule naming that client wouldn't have resolved if she'd copied it over from test. The first real candidate hits a flow that has already run end to end.