> ## Documentation Index
> Fetch the complete documentation index at: https://learn.workflow.dog/llms.txt
> Use this file to discover all available pages before exploring further.

# Branch Workflows

> Choose values, route execution, and combine conditions without hiding control flow.

Branching in WorkflowDog is data-driven. Conditions produce Boolean values,
and control actions either choose a value or emit data along one path.

## Choose a value or choose a path

The two basic patterns look similar on the canvas but behave differently:

<Tabs>
  <Tab title="Choose a value">
    [Choose Value](/reference/actions/control/mux) receives **If True**, **If
    False**, and a **Boolean Condition**, then emits exactly one value through
    **Result**.

    Both candidate inputs are dependencies of the action. Use this when the
    upstream values are already available and only the selected result matters
    downstream.
  </Tab>

  <Tab title="Choose a path">
    [Route Value](/reference/actions/control/demux) receives one **Value** and a
    **Boolean Condition**. It emits the value from either **If True** or **If
    False**. The other output emits no signal.

    A downstream node connected only to the unselected output is not attempted.
    Use this when different actions should run on different branches.
  </Tab>
</Tabs>

```text theme={null}
Choose a value:
approved text ─┐
rejected text ─┼─ Choose Value ─ Result ─ Send message
condition ─────┘

Choose a path:
record ───────── Route Value ─ If True  ─ Create approved record
condition ──────┘             └ If False ─ Request review
```

<Tip>
  If both branches ultimately feed the same action, choose a value first and
  connect one result. If the branches perform different work, route the value.
</Tip>

## Build conditions

Logic actions turn comparisons and checks into Boolean values:

| Need                   | Action                                            | Behavior                                                       |
| ---------------------- | ------------------------------------------------- | -------------------------------------------------------------- |
| Values are identical   | [Equal](/reference/actions/logic/equal)           | Uses strict equality; values of different types are not equal. |
| Values differ          | [Not Equal](/reference/actions/logic/not-equal)   | Uses strict inequality.                                        |
| Every condition passes | [And](/reference/actions/logic/and)               | Returns true only when every input is truthy.                  |
| At least one passes    | [Or](/reference/actions/logic/or)                 | Returns true when any input is truthy.                         |
| Reverse a condition    | [Not](/reference/actions/logic/not)               | Negates the input's truthiness.                                |
| Inspect truthiness     | [Is Truthy](/reference/actions/control/is-truthy) | Converts truthiness to an explicit Boolean.                    |
| Inspect falsiness      | [Is Falsy](/reference/actions/control/is-falsy)   | Returns true for a falsy value.                                |

Strict equality makes type conversions important. The number `1` and the
string `"1"` are different values. Convert first when data from an external
system represents numbers or booleans as text.

## Route by case

[Choose Value by Case](/reference/actions/control/mux-case) maps text keys to
values. It is useful for statuses, categories, event types, or any branch with
more than two outcomes.

<Steps>
  <Step title="Connect the case">
    Connect the text to compare, such as `priority` or `event_type`.
  </Step>

  <Step title="Add cases">Add one key and value for each recognized case.</Step>

  <Step title="Set a default">
    Provide **Default** for everything not listed. Without a default, an
    unmatched case returns `null`.
  </Step>

  <Step title="Use the result">
    Connect **Result** to the common downstream action.
  </Step>
</Steps>

Case keys are exact and case-sensitive. `"High"` and `"high"` are separate
cases.

<Note>
  Choose Value by Case selects data; it does not create multiple execution
  outputs. To run different actions, compare the case and use [Route
  Value](/reference/actions/control/demux), or add a **Conditional** meta
  control to each branch.
</Note>

## Supply fallback values

[Fallback](/reference/actions/control/coalesce) evaluates candidates in their
configured order and returns the first one that qualifies:

* **Non-Null** skips `null` values but keeps other values, including `false`,
  `0`, and an empty string.
* **Truthy** skips every falsy value.

Use **Non-Null** for optional fields where `false` or `0` is meaningful. Use
**Truthy** only when those values should also fall through.

## Gate one action

When a separate branch node would add noise, enable the **Conditional** meta
control on the action. Connect a Boolean condition to the new **Condition**
input. The action runs only when the value is truthy.

This is particularly useful for optional side effects:

```text theme={null}
order ────────────────────────────── Save order
  └─ amount > review threshold ──── Conditional: Notify reviewer
```

If the condition is false, the action is not attempted and its ordinary
outputs emit no signal. Downstream nodes that depend on those outputs will
also be skipped unless another path supplies their inputs.

See [Meta Controls](/building/meta-controls) for status outputs that report
whether a gated action was attempted or succeeded.

## Avoid ambiguous branches

* Name the condition in a nearby [Comment](/reference/actions/core/comment),
  especially when `true` and `false` are not self-explanatory.
* Normalize text before exact comparisons when capitalization or whitespace
  comes from users.
* Prefer one clear multi-case mapping over a long chain of nested binary
  choices.
* Preserve `false` and `0` with a non-null fallback when they are valid
  business values.
* Test both selected and unselected paths. A skipped node is different from a
  node that ran and returned `null`.