Dry-run mode

What this accomplishes

Test a workflow against fixture values for the nodes you choose, before it runs live.

A dry run runs a workflow’s real graph with fixture values swapping in for the nodes you choose, so you can check the logic before it touches anything live.

This page is the dry-run mode. The run inspector, where a dry run’s output lands, is in run inspector and replay.

Current availability

This page documents behaviour verified in Miton development builds. Miton is still pre-release and is not publicly downloadable; invited beta users will receive a signed desktop build with automatic updates.

Before you start

• A Miton development build, an active project and Automation open.
• A connected model plus permission for every file, network or scheduled action in the workflow.

How dry-run mode works

Dry run isn’t a persistent per-workflow toggle — it’s an action you take on demand: choose Dry run with sample inputs from the workflow toolbar (or the graph’s overflow menu). This opens a dialog listing every node in the graph, with a text field per node for a JSON fixture value.

• Any node you give a fixture for is short-circuited: its handler never runs, and the workflow uses your fixture as that node’s output instead.
• Leave a node’s field blank and it runs for real. Email, the approval gate, the file watcher, and the git event node all recognise dry run on their own and skip their side effect regardless — no email sends, no approval is created, no watcher state is recorded. The HTTP node does not have this guard: with no fixture supplied, it calls the real endpoint even during a dry run. If a node’s live call has a side effect you don’t want, give it a fixture rather than leaving it blank.

The development cycle

1. Build the workflow in the visual editor.
2. Test it with Dry run with sample inputs, supplying a fixture for any node whose real call you want to skip.
3. Ship — trigger the workflow for real (manually, or let its schedule or webhook fire it), and check the result in the run history.

What the dry-run mode does not cover

• Integration testing — dry run substitutes fixture values; it doesn’t verify what the real integration would actually return.
• Persistent dry-run state — there’s no toggle that keeps a workflow permanently in dry-run mode, and no saved fixture set that’s reused automatically across runs.
• Automatic side-effect suppression for every node kind — only email, approval, file watcher, and git event skip their live call without a fixture. Give the HTTP node a fixture explicitly if you don’t want it to hit the real endpoint.

What success looks like

You can test a workflow’s logic against fixture values without an email going out, an approval being created, or a watcher recording state — the log shows exactly which nodes ran for real and which used a fixture.

Common failures and recovery

• Inspect the failed run and the exact node output before running it again.
• Confirm credentials, permissions and test fixtures belong to the active project.
• Use a dry run to isolate a misconfigured node before starting the complete workflow again.

Related next action

Open the Automation overview to connect this task to the rest of the workflow.