Skip to content

Sandbox mode: overview

Sandbox mode runs your workflow on the real engine, but node calls to outside services never reach them. Use it while you build. Switch to Production when you are ready to run live.

The editor header switched to Sandbox: the frame around the canvas, Sandbox Executions, and the Run button reading Test Run.The editor header switched to Sandbox: the frame around the canvas, Sandbox Executions, and the Run button reading Test Run.

What it does

In a sandbox run, every node executes and every expression evaluates. Only the outbound calls are replaced:

Outbound call What happens in sandbox
HTTP requests from a node (connectors, HTTP Request and others) Answered by Flero's mock service with mock data
Email over SMTP Answered by a mock mail server. Nothing is delivered.
PostgreSQL and MySQL connections Answered by a mock database server
Any other network connection Blocked. The node returns a small stub instead of failing.

Credentials are still selected and resolved. Connector code still builds the request and sets headers. Loops iterate and conditions branch as normal. Downstream nodes receive the mocked data through the usual expressions.

Anything that happens in sandbox mode stays in sandbox mode.

What sandbox mode is not

  • Not a different editor. Configuration, credentials and expressions are the same in both modes.
  • Not a preview. Nodes really run and downstream nodes really receive upstream data.
  • Not a change to the workflow. Switching back to Production runs the same workflow live.
  • Not a sandbox for your own code. Code and Terminal nodes run exactly as they do live, including any network calls your snippet makes. Pin them if you need them inert.

When to use it

  • Building a new workflow. Check the wiring before you send real emails or create real CRM records.
  • Debugging. Re-run as often as you need without side effects.
  • Iterating on expressions. Get fast feedback without waiting on a real API.
  • Demoing. Show the workflow without firing a real Slack message at a customer.

When not to use it

  • Final acceptance testing. At some point you need to hit the real service.
  • Logic that depends on real values. Most mock data carries placeholder values, not real ones. See Mock data.
  • Performance testing. A mocked response does not reflect real latency.

How to turn it on

Use the Sandbox / Production switch in the editor header. Pick Sandbox:

  • A window-style frame appears around the canvas.
  • A toast confirms: "You are in sandbox mode. You can play and test your workflow with mockup data."
  • The Run button reads Test Run. In Production it reads Run Workflow.
  • The executions dropdown reads Sandbox Executions. In Production it reads Production Executions.

The mode is saved with the workflow. Switching counts as an unsaved change, so save the workflow to keep it. When you reopen the workflow, the editor restores the saved mode.

Production vs sandbox at a glance

Behaviour Production Sandbox
Outbound HTTP calls reach the service ✅ ❌ (mock data)
Emails are delivered ✅ ❌ (mock mail server)
External database writes happen ✅ ❌ (mock database server)
Code and Terminal nodes run for real ✅ ✅
Workflow logic and expressions run ✅ ✅
Pinned data replaces the node ✅ ✅
Run counts in Monitoring ✅ ✅
Run appears in the executions list ✅ ✅ (marked "Sandbox")

Which runs are sandboxed

Only runs you start from the editor with Test Run run in sandbox. Webhook, schedule and event-triggered runs always run live.

A Sub-Workflow node in a sandbox run runs its child workflow in sandbox too.

A rerun of a sandbox execution runs live. To repeat a dry run, use Test Run in the editor with Sandbox selected.

Found something out of date? This page lives in the Flero docs content set.