Testing in the builder
Fire the trigger for real, then read what happened. Two surfaces show the same run from different angles, and one field in it answers most questions.
A workflow that has never run is a drawing. Everything in this course so far has been about building; this lesson is the other half of the loop, and it is the half that separates people who ship automations from people who have a lot of drafts.
Test by firing the trigger for real. Change the record. Post to the webhook. Type into the chat. Whatever starts this workflow in production is what should start it now — because a test that skips the trigger has not tested the part most likely to be wrong.
Two ways to read a run
Once it fires, the same run is visible in two places. They hold identical data and are useful at different moments.
| Surface | What it is for |
|---|---|
- What it is for
- What it is for
The sequence is always the same: the panel tells you where, the node tells you why. Going straight to a node's panel without looking at the list first is how people spend twenty minutes debugging a node that ran perfectly.
What a run actually contains
Whichever surface you read it through, a run is the same record underneath, and it is worth knowing its shape:
| Field | What it tells you |
|---|---|
| status | |
| failed nodes | |
| duration | |
| per node: output | |
| per node: output path |
status
- What it tells you
failed nodes
- What it tells you
duration
- What it tells you
per node: output
- What it tells you
per node: output path
- What it tells you
The output path is the field to look at first on any branching workflow. A Condition records not just that it ran but which way it went, alongside the two values it compared. When a workflow “does the wrong thing”, this one field usually ends the investigation in seconds — the branch went the way it went because those were the values, and now you can see them.
How to read a run that went wrong
- Find the last node that ran. If the list stops earlier than the canvas does, the workflow left down a path you did not expect, or a node ended the run.
- Read its output path. On a branch, compare the two values it recorded. Nine times in ten the values explain everything.
- Open the node after the surprise, not the one before it. Look at the runtime input it received. If a value is empty or contains angle brackets, the problem is upstream of it, and now you know exactly where.
- Compare what a node produced with what the next node referenced. Field names are the most common defect in this whole course — a template referencing a field that the producing node does not emit resolves to nothing, silently.
What breaks
A green run is not a correct run, and this course has spent twenty lessons proving it. A campaign that mailed nobody, a text-to-speech node that produced no audio, a search that quietly answered a different question, a reply containing <field not found> — every one of those is a completed run with no failed nodes. Testing means reading the output, not reading the status.
Testing with data that is too clean proves nothing. The first run should use a realistic record — a contact with a missing phone number, a name with an apostrophe, an empty optional field. The workflow that works on your carefully filled test contact and breaks on the third real one is the standard experience.
Firing a real trigger has real consequences. There is no sandbox. Testing a workflow that emails, calls or charges someone does those things. Point the recipient at yourself, set a small limit on any search feeding a bulk step, and read the previous lessons' warnings about caps before rather than after.
A workflow that is not active will not fire. It is the most common reason a trigger seems to do nothing, and it is invisible unless you look — the record changes, the webhook returns success, and no run appears at all. If there is no execution to read, check this before anything else.
Try it
- Take any workflow you have built and fire its trigger properly. Do not simulate it.
- Read the run end to end before forming an opinion: which nodes ran, in what order, and what the last one produced.
- Open one node's panel afterwards and read the runtime input it received. Compare that against what the node above it produced.
- Now break something deliberately — misspell a field name in a template — and run it again. Find the defect from the run alone, without looking at your edit.
- Finally, run it with a deliberately awkward record: blank optional fields, an apostrophe in a name. That is the run that tells you whether it is finished.
Next: The executions panel — the same information, kept, for every run that ever fired rather than only the last one.
Related lessons
Base rates — what a piece of evidence is actually worth
A face-recognition system that is 99.9% accurate and almost entirely wrong, and a number that sent an innocent woman to prison. Both are the same arithmetic, and it is the arithmetic that decides what any piece of evidence is worth.
ReadConfirmation and survivorship — what you never looked for
Two questions about evidence you did not go looking for. One is a rule you have to discover, and one is a pattern in five famous people — and in both, the thing that would have told you the truth is the thing nobody checks.
ReadLoss aversion, sunk cost and regression — what it costs you
Four questions you answer about yourself rather than about a scenario, and your own answers are the finding. Then the pattern that makes praise look useless and criticism look like it works, whatever you actually do.
Read