Node: Condition

What does the Condition node do?

The Condition node splits an automation into different paths based on a rule.

Everything before a Condition node happens for everyone. After the Condition node, what happens depends on the employee — their office, department, team, employment type, and so on. One automation can give different treatment to different people.

When should I use the Condition node?

• Onboarding across offices. The welcome message and first-day tasks are the same everywhere, but IT setup differs between offices. One automation, a Condition node, two paths.
• Different managers for different departments. Sales onboarding includes a CRM access task; Engineering onboarding includes a repository access task. Everything else is shared.
• Employment type. Permanent employees get the full probation and benefits sequence; temporary and contract staff get a shorter path.

Tip: The signal to reach for a Condition node: you are about to build a second automation that is 80% identical to one you already have, differing only in who gets which task. That is a Condition node, not a second automation. Keeping it as one automation means you maintain the shared steps once instead of twice, and you can see the whole process in a single view.

What settings does the Condition node have?

Label: The name of the step as it appears on the canvas. Required. Write it as the question the step is answering, for example “Which office?” or “Permanent or temporary?”, so another admin can read the canvas without opening the step.

Branches: Each branch is one path out of the Condition node, with its own rule. Click a branch to edit it. A rule is built from checks, and each check has three parts: 

• Field (what you are testing, for example office, department, team, or employment type)
• Operator (how you are testing it, for example “is”)
• Value (what you are testing against).

Use Add check to put more than one check on a branch, for example office is Oslo and employment type is permanent.

Branches name themselves after their rule, so a branch checking office is Oslo will label itself accordingly on the canvas. Use Rename if you want something clearer.

Note: A branch shows as Incomplete until its rule is filled in. An automation with incomplete branches cannot be published.

• Otherwise: Every Condition node has an Otherwise branch, and you cannot remove it. It catches everyone who does not match any of the branches above.
• Add branch: Adds another path. Use one branch per distinct outcome.

What happens when a Condition node runs?

When a run reaches the Condition node, the branches are checked against that employee’s record as it is at that moment. The run then continues down the matching branch only. Steps on the other branches do not run.

Anyone who matches no branch goes down Otherwise. If Otherwise has no steps on it, the run simply ends there — nothing happens for that employee, and the run is recorded as completed.

The run history shows which branch was taken, so you can check afterwards why a particular employee got one path and not another.

Common mistakes and limitations with the Condition node

• Paths do not rejoin. Once the automation splits, the branches run separately to the end. If a step needs to happen for everyone, put it before the Condition node, or accept that you will add it to every branch and maintain it in several places.
• Otherwise is where people quietly disappear. An empty Otherwise branch means anyone who does not match gets nothing, silently. Before publishing, check who ends up there — usually it is employees with a blank field, such as no office set. Either add steps to Otherwise, or put a task on it telling HR to handle that person manually.
• Missing data does not match anything. An employee with no department set will not match a department branch. They go to Otherwise. This is the most common reason someone “got the wrong path”.
• Rules are evaluated once, when the run reaches the node. If the employee changes department later in a long-running process, the run stays on the branch it took.
• Do not rebuild scope here. A Scope node decides who enters the automation at all; a Condition node decides how they are treated once inside. If an employee should not be in the process, narrow the scope — do not let them in and then route them to an empty branch.
• Too many branches is a sign the process is really two processes. Three or four paths is readable. Nine is not, and probably means the automations should be separated after all.
• Editing branches does not affect runs already in progress. Those runs continue on the version, and the branch, they started with.