Skip to content
Docs
flero.ai

Sandbox mode, user guide

Day-to-day patterns for working with sandbox mode.

📸 Screenshot needed: sandbox__mock-data-pin.png, an HTTP node inspector with a green "Mocked" badge on the output panel and a "Mock data source: Pinned (custom)" label below.

The four sources of mock data

When a sandbox-mode node needs to return a value, Flero looks in this priority order:

  1. Pinned data on the node, if you've manually pinned an output, it wins.
  2. The workflow's mock-data store, recorded outputs from previous real runs. Promoted via Save as mock on an execution.
  3. Connector-provided defaults, every connector ships sample responses for each operation.
  4. Generic synthesised data, last resort. Shape matches the documented schema; values are random.

Each node's inspector shows which source is active for its output (green "Mocked" badge with the source name).

Pinning custom mock data

In any node's inspector, expand the Output panel → Pin custom data. Paste JSON. From now on, sandbox runs of this node return that JSON.

Use when:

  • You want to test a specific edge-case response (the unusual user, the failed payment, the empty list).
  • The connector's default mock doesn't reflect your specific shape.

Pinned data persists across saves and shows up as a "Pinned" badge in the editor. Unpin to fall back to the next priority source.

Recording real responses as mocks

Run the workflow in production mode against a known-safe input. After the run, open the execution detail → on the failed or interesting node → Save as mock.

That node's output is now stored in the workflow's mock-data store and replayed on future sandbox runs.

For full mock-data tooling (promote across workflows, manage the store), see the CLI reference (developer guide).

Auto-approve in sandbox

By default, Approval nodes pause in sandbox just like in production. Most of the time you don't want this when iterating.

Workflow settings → Sandbox → Auto-approve approvals. With this on, sandbox runs auto-approve every Approval node after a 1-second pause (so you can still see the pause in the execution detail).

The data passed to the approved branch is the same as a real approval, with a synthetic approval.approvedBy of sandbox.

Mixing sandbox and real

By default it's all-or-nothing, a run is either sandbox or production. For mid-workflow real calls (rare), individual nodes have a Disable sandbox for this node toggle in their inspector → Advanced. The node behaves normally even when the run is sandboxed.

Use sparingly, it's a foot-gun (you'll forget it's on and send a real charge during testing).

Confidence-building workflow

The pattern that works well for most teams:

  1. Build the workflow in sandbox. Iterate quickly.
  2. When it looks right, do a single production run with a known-safe input (your own email address, a $0.01 test charge).
  3. Inspect every node's output, does it match what you expected?
  4. Save mock data for the run.
  5. Flip status to Active.

The saved mock data now backs future sandbox runs, they replay exactly what production did, but no longer hit the live service.

Tips & gotchas

  • Pinned data doesn't expire. Easy to forget. If your sandbox is suspiciously stable, check the inspector for pinned indicators.
  • Mock data has the shape but not always the constraints. A mocked payment will never get declined, so error paths might not be exercised. Add explicit Pinned data for error scenarios.
  • AI Agent in sandbox returns either a cached prior response (if memory + key match) or a synthetic placeholder. To exercise specific AI behaviour, pin a mock response.
  • Subscriptions / webhooks created in sandbox are not real. A workflow that creates a Stripe subscription in sandbox isn't actually creating it, careful when reading the response back to set further state.

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