You do not want the same automation to give everyone the same answer: a returning customer needs one thing, a first-time visitor another. That is exactly what a condition step does — it looks, decides, and splits the flow into a branch and a branch. This guide walks you through building the step from scratch, combining rules and planning both branches properly.
True
False
💡 This guide covers building the step. For what a condition is and the full list of rule kinds, see Condition.
In this article you will find:
Adding a condition step
Adding, changing and removing rules
All must match versus Any is enough
Connecting the True and False branches
Splitting into more than two paths
Reading the decision from the logs
Limits and known issues
Common mistakes
Adding a condition step
A condition step is added to the canvas like any other step.
Open the automation and stay on the Flow tab.
Open the Add step menu in the top bar.
Choose Condition. A new box appears on the canvas with the note "Splits the path by person."
Tap the box; the settings panel opens on the side.
In the step's Connections section, connect the True and False outputs to a step each.
If you would rather add the step already connected, use the Add and connect a step menu inside the previous step's Connections section; the new step is both added and attached to that output.
Adding, changing and removing rules
A condition step asks nothing on its own; the questions live in its rules.
In the settings panel, press Add rule. The panel adds a Tag rule by default.
Pick the kind in the first dropdown: Tag, Field, Channel, Last reply, Assignment, Time range, Day, Incoming attachment, Business hours, Messaging window, First contact, Follow state, Contact's language, Started by, Post or Trigger counter.
Pick the operator in the second dropdown (has, contains, is empty, is and so on).
Type the value or choose it from the list, if the operator needs one.
To delete a rule, tap the cross button at the end of its row.
Changing a rule's kind resets the row: the new kind arrives with its own default operator and an empty value. If you pick the wrong kind and switch back, you have to type the value again.
The list of rule kinds is filtered by the account's channel. On a WhatsApp-only account, Follow state and Post never appear, because neither exists on WhatsApp. If only one channel is connected, the Channel rule is not listed either: there is nothing left to ask.
⚠️ Note: A rule that was saved earlier is never removed, even when it has no counterpart on the current channel, and it stays in the list. If you changed your account's channel, read the warnings in the pre-publish check.
All must match versus Any is enough
The Rules box at the top of the panel says how several rules combine:
All must match — the flow takes the True branch only when every rule is true. A single false rule sends it to False.
Any is enough — the flow takes True as soon as one rule is true.
When choosing, ask yourself: do the rules complete each other, or are they alternatives? "Inside business hours and the contact is VIP" is a completion, so All must match. "The contact has wholesale or reseller" is an alternative, so Any is enough.
The more rules you pile in, the harder it gets to read what the step asks. Instead of squeezing more than three rules into one step, put two condition steps back to back — it reads better both on the canvas and in the logs.
Connecting the True and False branches
A condition step has exactly two outputs, and both are listed in the Connections section of the settings panel:
True — the path taken when the rules are satisfied.
False — the path taken when they are not.
To connect an output, choose the target step in the dropdown next to it. An unconnected output shows Not connected, and the pre-publish check warns that the output is not connected to a step.
An unconnected output is not an error; the flow simply ends when it gets there. Sometimes that is what you want (there may be nothing to say in the "already a customer" branch), but more often it is a branch you forgot. If you are leaving it empty deliberately, add a Note step next to it and write down why.
💡 One output carries one connection. If you attach a second step to the same output, the new connection replaces the old one. To run two steps one after the other, connect them to each other.
Splitting into more than two paths
A condition never has more than two branches. When you need three or more paths, chain conditions like a ladder:
First condition: "Does the contact have the vip tag?" → True: the VIP message. → False: connect to the second condition.
Second condition: "Does the contact have the reseller tag?" → True: the reseller message. → False: connect to the third condition.
The third condition catches the most general case; its False branch goes to the default message everyone gets.
Put the most frequent case at the top of the ladder: the flow finishes sooner and the canvas stays readable from top to bottom.
If you want to split paths at random rather than by the person's situation, you need the Random split step instead of a condition; that is how you compare two messages (A/B).
Reading the decision from the logs
You never have to guess which branch a condition picked.
Open the automation and switch to the Logs tab.
Open the session you want to inspect.
Find the Condition line in the step-by-step log. The line shows the outcome.
Some rules also write the value they based the decision on: the Follow state rule records "follows / does not follow / unknown" and, when relevant, that the value was refreshed from Instagram; the Messaging window rule records "open / closed". The answer to "why did it take the wrong branch" is almost always on that line.
To try a change before publishing, the simulation on the Test tab runs the same rules. The only difference is the Trigger counter: in the simulation it does not really count and always reads as "not full".
Limits and known issues
A condition step holds at most 20 rules.
With no rules at all, a condition is not satisfied and the flow takes the False branch. The pre-publish check reports this as an error ("Add a rule to the condition").
A rule with an empty value is also an error ("A rule is incomplete"). The is empty and is filled operators need no value, so they never raise it.
The Trigger counter must be alone in its own step. Combined with another rule, publishing is blocked.
Every rule kind is covered by your plan separately. You can add a rule your plan does not cover, but the session stops when it reaches that step and a "Plan lock" line is written to the log.
If every rule in a condition inside a loop that never waits for the person is of a kind that cannot change within the loop (tag, channel, language and so on), the pre-publish check warns you: the flow takes the same branch every time and the loop never breaks.
Common mistakes
Forgetting to connect the False branch. The flow ends quietly there and the customer gets no answer.
Confusing All must match with Any is enough. Looking for one of three tags needs Any is enough; with All must match nobody carries all three.
Filling one step with too many rules. Twenty rules are technically possible but nobody can read them months later.
Expecting a condition to change something. A condition only looks. To add a tag, write a field or assign a conversation, see The action step and ordering.
Changing a rule's kind and expecting the value to survive. The row resets.