Module · The Builder
Variables in action
Lesson 8 of 9 · 3 min
You have written references and you have been told what they mean. Whether they are right is a different question, and there is only one way to answer it: run the workflow and look.
This is the skill the rest of the course assumes. It is not difficult; it is just a habit that nobody tells you to form.
What a run gives you
Once a workflow has run, every node it touched can tell you three things:
| What you can see | What it answers |
|---|---|
| What arrived | |
| What it was configured with | |
| What it produced |
What arrived
- What it answers
What it was configured with
- What it answers
What it produced
- What it answers
The third one is the answer to “what can I reference?” Rather than guessing a field name or reading documentation, run the workflow once and read what the node actually emitted. That list is the truth, and it is always shorter and stranger than you expected.
Reading a branch
Nodes that make decisions record more than their result. A Condition keeps the two values it compared and which way it went — so a workflow that “did the wrong thing” usually explains itself in one line.
A real example from a workflow in this course: a Condition checking whether a search found anything recorded that it compared 0 against 0 with a greater-than, came out false, and left down the false branch. There is nothing left to investigate. The search found nothing, so the “nothing found” reply fired, which is correct — and the thirty seconds spent reading that is thirty seconds not spent rebuilding a workflow that was fine.
The four questions, in order
- Did it run at all? If there is no execution, the trigger did not fire, and no amount of reading node configuration will explain that. Check the workflow is active.
- How far did it get? If the run stops earlier than the canvas does, it took a path you did not expect. Read the branch.
- What did the last good node produce? Compare that against what the next node was trying to read. Mismatched field names are the most common defect in the whole product.
- Is the value empty, or is it angle brackets? Empty means the data was missing. Angle brackets — a literal “not found” in the text — mean the reference was wrong. Different problems, different fixes.
What breaks
Reading the status instead of the output is the mistake this entire course is arranged around. A run that completed with no failed nodes can have sent an email to nobody, produced no audio, mailed an empty list, or replied with a placeholder in the text. None of those are errors. All of them are visible in the output of one node, in the run you already have open.
Test data that is too tidy hides everything. Your test contact has a first name, a last name, an email and a phone number. Real ones do not. Run it once with a deliberately incomplete record and read the output again — that is the run that tells you whether the workflow is finished.
A node that was not reached has no data, and looks identical to one that failed. If a node has nothing to show, the question is not what it did wrong — it is why the run never got there.
Try it
- Run any workflow you have built and open the last node. Read its output before forming any opinion about whether it worked.
- Now open the node before it and compare: what that one produced against what this one was trying to read. Do that once and the habit sticks.
- Deliberately misspell a reference, run it, and find the angle brackets in the output. That is the shape of a typo.
- Fix it, then run it against a record with the field genuinely blank. That is the shape of missing data. They look different and it matters.
- Finally, run a workflow that branches and read which way it went and why. The recorded comparison is the whole answer.
Next: Configuring workflow details — the last lesson, and the one that decides whether anybody can find this workflow in six months.