Adding logic: conditions and branches
Every workflow so far has been a straight line: this, then this, then this. Real processes are not straight lines. A qualified lead should reach a human; everyone else should get the automated version. Same trigger, same starting data, two different endings.
That is one node — the Condition — and one new idea: after it, the workflow is running on one path, not both.
A workflow with two endings
Qualified leads go to a person. Everyone else gets the email.
The first four-node workflow in this course that does not run all four nodes. Exactly one of the bottom two ever happens.
Scroll for all 4 steps →
The condition's whole configuration is three fields, and they read as one sentence: take {{new_contact.new_data.lead_status}}, compare it == against qualified. That is it. There is no scripting here — a condition is a sentence with three blanks.
Yes and No are wires, not settings
Look at the two arrows leaving the condition. Those labels are not something anyone typed — they are the node's two outputs, and connecting a node to one of them is how you say “do this when the answer is yes”. A condition with nothing wired to an output is a dead end: the workflow reaches it, the answer comes back, and there is nowhere to go.
You do not have to wire both. A branch that goes nowhere simply ends, and that is a perfectly good design — “if the lead is qualified, make a task; otherwise do nothing” is one wire, not two. There is no “end” node to add. Nothing is left dangling.
Only one side runs
This is the part that trips people who are used to reading code top to bottom. The two nodes under the condition are not steps two and three. They are alternatives. When this workflow ran with a qualified lead, the task was created and the email node did not execute at all — it does not appear in the execution log, because it never happened.
Which means a node after a branch cannot count on the other side's output. If a later node referenced {{nurture.message_id}} on a run that took the Yes path, it would find nothing — the node that produces it never ran. When you need both paths to rejoin, wire them both into the same next node, and write that node so it works whichever way the workflow arrived.
Picking the test
A condition compares two values, and the operator decides how. == and != for exact matches, contains and starts_with for text, is_empty and is_not_empty for “did we ever get this?”, plus a set of date operators for deadlines and anniversaries.
| Field | What it holds |
|---|---|
variable | Variable to evaluate (supports legacy value_path) |
operator | Comparison operator One of: == · != · > · < · >= · <= · contains · not_contains · starts_with · ends_with · regex_match · is_empty · is_not_empty · greater_than · less_than · in · not_in · before · after · date_between · date_equals · within_last_days · within_next_days · time_before · time_after · time_between · time_equals Defaults to ==. |
value | Value to compare against (supports legacy comparison_value) |
variable
- What it holds
- Variable to evaluate (supports legacy value_path)
operator
- What it holds
- Comparison operator One of:
== · != · > · < · >= · <= · contains · not_contains · starts_with · ends_with · regex_match · is_empty · is_not_empty · greater_than · less_than · in · not_in · before · after · date_between · date_equals · within_last_days · within_next_days · time_before · time_after · time_between · time_equalsDefaults to==.
value
- What it holds
- Value to compare against (supports legacy comparison_value)
is_empty is worth knowing early. The most useful branch a beginner can build is not clever routing — it is “did this field actually arrive?”. A workflow that checks before it uses a value fails politely instead of sending a message addressed to nobody, which is the failure lesson 4 warned about.
When one condition isn't enough
A condition asks one yes/no question. Three or more outcomes — hot, warm, cold — is a Multi Condition instead, which has a named path per case and a default for everything that matched nothing. Reach for it when you notice yourself chaining conditions into a staircase; two levels deep is usually fine, four is a sign the shape is wrong.
Key takeaways
- A Condition is three fields: a variable, an operator, and a value.
- Yes and No are outputs you wire, not settings you fill in.
- Only one branch runs. The other side's nodes do not execute and produce no output.
- A branch wired to nothing just ends — there is no end node, and one wire is a valid design.
- Rejoin by wiring both branches into the same node, and write that node to work either way.
- Three or more outcomes means a Multi Condition, not a staircase of conditions.
Try it yourself
Take the workflow above and answer this: if a contact arrives with no lead status at all — the field never filled in — which path does it take, and is that what you would want? (It takes No, because an empty value is not equal to “qualified”. Whether that is right depends on whether an unknown lead deserves the welcome email or a human's attention — which is a business decision the node cannot make for you.)
Next: The AI Agent node — the one node that decides what to do instead of being told.
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