Testing Flows
A Flow touches real data and sends real messages. Test it before it reacts to live events.
A test run is not a dry run
A test actually executes the Flow: emails go out, entries are created and changed, outside systems get called.
Use your own email address and test records when testing — not real customer data.
The test types
The editor offers several ways to run a Flow:
| Button | Description in the interface |
|---|---|
| Run Flow | Starts the Flow |
| Test Flow | Uses the last row of the Grid |
| Restart | With data from the last execution |
| Start with test data | Provide sample data |
| Wait | Wait until the Flow runs again |
| With data from the Flow form | Open the form and test with submitted data |
Test Flow
The fastest way. Takes the last row of the Grid as input.
Keep a test row in place
Since it always uses the last row, it's worth maintaining a test record at the very bottom of the Grid — with your own email address and clearly recognizable values like TEST Smith.
Restart
Repeats the Flow with the data from the last run. Ideal when fixing an error: you change a setting and re-run the same input data.
If there was no previous run yet, the editor reports No previous execution found.
Start with test data
You provide the input data yourself as a sample. The right approach for the Webhook trigger, where the data would otherwise come from outside.
Wait
The editor waits for the next real run and shows its data. Useful for observing what happens during actual use.
With data from the Flow form
Opens the associated form. What you submit there becomes the test input. The most realistic test for form-based Flows.
Is the Flow even ready to test?
If everything is fully configured, the editor reports:
The Flow is ready to be tested
If something's missing, this appears instead:
Flow still has errors
Go through the steps then — an incompletely configured step is marked in the editor.
Viewing results
After a run, the editor shows the data of that run. The hint reads Displaying previous executions — so you're not looking at the blueprint, but at concrete values.
Displayed are the execution time, status, and number of steps. Select other jumps to a different run, Reset leaves this view.
Run status values:
| Status | Meaning |
|---|---|
| Completed / Done | Ran through fully |
| Failed / Error | Aborted |
| In progress | Currently running |
| Waiting | Waiting on an event, e.g. page input |
| Test run | A test run, not a real execution |
Narrowing down errors
On every step, Show details leads to input and output data, and on problems, Show error details leads to the error message.
A tried-and-tested approach:
- Where does it break off? The history shows how many steps ran.
- What came in? Check the output at the last successful step via Show details.
- What did the failing step expect? Often a field doesn't match the expected format.
- Change and repeat with "Restart". Same input, changed configuration.
Common causes
| Symptom | Likely cause |
|---|---|
| Flow doesn't start at all | Trigger points to a different Grid or form than intended |
| Flow suddenly stops starting | The switch is set to off — possibly automatically after three identical errors |
| Flow starts too often | Entry was changed without a field condition |
| Flow starts endlessly | An action writes to the same Grid that triggers the Flow |
| Email doesn't arrive | Recipient field empty because the field value wasn't set |
| Empty values in the message | Reference to a step that hasn't delivered anything yet |
| Only one entry instead of many | Load all entries without a following Parallel |
| Flow still has errors | A step is incompletely configured |
Break infinite loops
If a Flow triggers itself, runs keep piling up. Switch it off first via the switch — this stops immediately, including runs currently in progress. Then calmly change the trigger or the target of the writing action, switch it back on, and check the history to make sure no new runs are being created.
Before going live
A short checklist:
- [ ] Test run completed without errors
- [ ] Tested a real submission, not just the editor test
- [ ] Recipient addresses checked — no test addresses left
- [ ] For writing actions: no possibility of self-triggering
- [ ] For webhook triggers: URL not stored somewhere publicly accessible
- [ ] Test records removed from the Grid