> ## Documentation Index > Fetch the complete documentation index at: https://docs.collabase.ch/llms.txt > Use this file to discover all available pages before exploring further. > Condition nodes evaluate data and decide whether an automation branch continues, stops, or takes an alternate path. # Conditions # Conditions Condition nodes sit between your trigger and your actions. They evaluate a value — from the trigger, a previous action, or a stored variable — against a rule you define. Based on the result, execution continues, stops, or takes a different path. Use conditions to make automations precise. Instead of notifying someone every time any task changes, add a condition to proceed only when the priority is `HIGH`. Instead of creating a Jira issue for every webhook, limit it to requests where the environment is `production`. *** ## Two condition node types | Node | Behavior when the condition is false | | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Filter** | The branch stops silently. No downstream nodes run. No error is logged — a stopped branch is expected, healthy behavior. | | **IfElse** | Execution always continues — on the **true** path if the condition passes, on the **false** path if it does not. Both paths can have their own actions. | Use **Filter** when you want the automation to do nothing if the condition is not met. Use **IfElse** when you want different actions depending on the outcome. A branch stopped by a Filter node does not count as a failed execution. The Runs tab shows it as stopped at that node, which is correct behavior. *** ## Operators | Operator | Works on | Description | | ----------------------- | -------------------- | ------------------------------------------------------------------ | | `is` | Text, number, status | The value exactly matches what you enter (case-sensitive for text) | | `is not` | Text, number, status | The value does not match | | `contains` | Text | The value includes the given text anywhere | | `does not contain` | Text | The value does not include the given text | | `starts with` | Text | The value begins with the given text | | `ends with` | Text | The value ends with the given text | | `is empty` | Any | The field is blank, null, or missing | | `is not empty` | Any | The field has any value | | `greater than` | Number, date | The value is larger than the given number | | `less than` | Number, date | The value is smaller than the given number | | `greater than or equal` | Number, date | The value is at least the given number | | `less than or equal` | Number, date | The value is at most the given number | | `is in last N days` | Date | The date falls within the past N days from now | | `is in next N days` | Date | The date falls within the next N days from now | *** ## Expression syntax The field you evaluate can be any value from an upstream node. Use the same variable syntax as action fields: | Reference | Example | | --------------------- | --------------------------------- | | Trigger payload field | `{payload.environment}` | | Nested payload field | `{payload.task.priority}` | | Specific node output | `{stepOutputs.createTask.status}` | | Stored variable | `{variableName}` | **Example — check if a webhook came from production:** | Field | Operator | Value | | ----------------------- | -------- | ------------ | | `{payload.environment}` | `is` | `production` | **Example — check task priority:** | Field | Operator | Value | | ------------------------- | -------- | ------ | | `{payload.task.priority}` | `is` | `HIGH` | *** ## AND / OR combinators A single condition node can contain multiple rules. Use the combinator setting to control how they combine: | Combinator | Behavior | | ------------------------ | ------------------------------------------------ | | **All conditions (AND)** | Every rule must pass for the node to pass | | **Any condition (OR)** | At least one rule must pass for the node to pass | The combinator applies to all rules within the same node. To mix AND/OR logic across groups of rules, chain multiple condition nodes. *** ## Router node — multi-way branching The **Router** node extends branching to more than two paths. Define as many routes as you need, each with its own set of conditions. When the router evaluates: * The first route whose conditions pass is followed. * Subsequent routes are not evaluated (first match wins). * If no route matches, the **default** path runs (if configured). Use a Router when you have three or more distinct outcomes — for example, routing a task based on priority: | Route | Condition | Actions | | -------- | ---------------------------------- | ----------------------------------- | | Critical | `{payload.priority}` is `CRITICAL` | Page on-call + create Jira incident | | High | `{payload.priority}` is `HIGH` | Send Slack alert | | Default | (no condition — always matches) | Log only | *** ## Examples **Only proceed if task priority is HIGH — stop otherwise:** Use a **Filter** node. | Field | Operator | Value | | -------------------- | -------- | ------ | | `{payload.priority}` | `is` | `HIGH` | *** **Send a Slack alert for HIGH priority, log only for everything else:** Use an **IfElse** node. | Field | Operator | Value | | -------------------- | -------- | ------ | | `{payload.priority}` | `is` | `HIGH` | * **True path** → Slack: Send Message * **False path** → Data Store: Log event *** **Only proceed if a webhook is from production and has a version set:** Use a **Filter** node with **All conditions (AND)**. | Field | Operator | Value | | ----------------------- | -------------- | ------------ | | `{payload.environment}` | `is` | `production` | | `{payload.version}` | `is not empty` | — | *** **Route a task by priority across three outcomes:** Use a **Router** node with three routes as shown in the table above.