Sandbox mode: user guide

Day-to-day patterns for working in sandbox mode. You need no code and no setup, just the editor.

Switching modes

The editor header has a two-segment Sandbox / Production switch.

The mode is stored with the workflow. Switching marks the workflow as having unsaved changes. Save to keep the mode. When you reopen the workflow, the editor restores it.

Running in sandbox mode

Press Test Run. The run goes through the normal queue and engine, and each node runs inside the sandbox:

• Credentials are still selected and resolved. Connector code still builds the request.
• Expressions still evaluate. {{ $trigger.payload.email }} resolves against the trigger data.
• Network calls do not leave Flero. HTTP requests get mock data. Email and PostgreSQL or MySQL connections are answered by mock servers. Other connections are blocked and the node returns a stub.
• Sub-workflows inherit the mode. A Sub-Workflow node runs its child in sandbox too.
• Sandbox runs appear in the executions list, marked with a small dot whose tooltip reads "Sandbox".

Click any node in a finished sandbox run to see its output, exactly as for a live run. The output is whatever the mock data layer returned.

Pinning data on a node

Pin a node's output when you want that node to return a fixed response on every run.

Pinning from a run

1. Run the workflow once (live or sandbox) so the node has output.
2. In the node inspector's Output tab, click Pin Data. The button is disabled while the node has no output.
3. The Pin Data pill switches to its selected style and the pushpin icon tilts, on the canvas card and in the panel header.

From then on, every run of the workflow skips that node's real work and returns the pinned payload instead. Downstream nodes receive it through the normal expressions.

Pins apply in Production too. A pinned connector node does not call its service on a live run either. Unpin before you go live.

If you pin a trigger, the pinned payload also restores the trigger data for runs that have none of their own. {{ $trigger.payload.X }} expressions then resolve as they did in the run that produced the pin.

Editing pinned data

The Output tab has an Edit JSON button next to Pin Data:

• The JSON view becomes an editor.
• Save checks that the JSON parses and that the top level is an object. An array or a plain value is rejected with an "Invalid JSON" error. Saving an edit pins the node.
• Cancel discards the changes.

Use this to handcraft a payload without capturing it from a real run first.

Multi-item outputs

If the pinned payload holds a non-empty _items list, each entry replays as its own item for downstream nodes. That keeps the fan-out of the original run. Otherwise the payload is emitted as a single item.

Unpinning

On a pinned node, click Pin Data again. The pin is cleared and the node runs normally on the next run. In sandbox, that means it gets mock data again.

Pins live in the workflow

Pinned data is part of the workflow's saved configuration. Save the workflow after pinning, or the pin exists only in your editor session. Pins travel with exports and imports.

Common patterns

Test end to end before going live

Switch to Sandbox, run, and walk through each node's output in the inspector. Fix anything that looks wrong (an expression, a field name, a shape) and run again. When the data looks right, switch to Production and run live.

Make a test case deterministic

Run once with the inputs you care about. Pin the outputs on the relevant nodes. Run as often as you need. Unpin when you are done.

Test error handling with a crafted payload

Open the node, click Edit JSON, type the payload and Save. Run. The node returns exactly what you wrote, and downstream nodes process it.

Mock data looks wrong

Most mock data is either generated from the service's published schema or carries placeholder values. Pin a better response yourself. See Mock data.

Limits and things to know

• Code and Terminal nodes are not sandboxed. They run as in a live run, so a snippet that makes its own network calls makes them for real. Pin the node if you need it inert.
• Local SQLite files are not intercepted. They are files, not network connections.
• Unknown connections return a stub. A connection to anything other than a mail server or a PostgreSQL or MySQL database is blocked. The node returns { "sandbox": true, "intercepted": true, ... } so the run continues.
• Rerun does not keep the mode. Rerunning a sandbox execution starts a live run. Use Test Run to repeat a dry run.
• Sandbox runs count in Monitoring. Its totals and charts include them alongside live runs.
• Sandbox runs still use compute. Only the outbound call is skipped. Queueing, expression evaluation, progress updates and storage all happen as normal.
• Approvals still pause. An Approval node waits for a decision in sandbox, as it does live.
• Flero's own notifications still go out. Approval request emails and run result emails come from Flero, not from a node, so the sandbox does not stop them.

Related

• Overview
• Mock data
• Troubleshooting
• Testing a node

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