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

# Use conditions and branches

> Control workflow behavior with conditions, branching, waiting, and early exits.

## Not every workflow should do the same thing every time

Many automations need to make decisions based on the input they receive.

Examples:

* continue only if a record meets certain criteria
* route different requests to different destinations
* stop early when required data is missing
* wait before taking the next action

That is where conditions and control-flow steps become useful.

## Use branching when the workflow outcome depends on the input

Branching is a good fit when one workflow needs multiple possible paths.

Use it when the workflow should ask:

* is this important enough to continue
* where should this be routed
* should it be handled one way or another

This is usually better than creating several almost-identical workflows that differ only by one rule.

## Keep condition logic easy to explain

A good branch should make sense in one sentence.

For example:

* if the lead is high intent, notify sales
* if the message is low priority, store it without alerting anyone
* if required data is missing, stop the workflow

If the condition is hard to explain, it may be too complex for the current version of the workflow.

## Use wait steps intentionally

Wait steps are helpful when:

* a downstream system needs time before the next action
* the workflow should delay a follow-up
* the process should pause between stages

Use waits because the business process needs them, not because the workflow logic is unclear.

## End early when continuing would waste work

Sometimes the best result is to stop the workflow.

That is useful when:

* the input is incomplete
* the record does not meet the workflow criteria
* the result would not be useful enough to keep processing

Ending early is often cleaner and cheaper than letting unnecessary steps run.

## Design for predictable outcomes

When adding conditions, optimize first for:

* readability
* predictable behavior
* easy testing

You can always make the logic more sophisticated later. Branches that are too clever too early are harder to maintain.

## Test each branch deliberately

Do not assume the branch logic is correct just because one path worked.

Where possible, test:

* the true path
* the false path
* the early exit behavior
* any wait or delayed behavior that matters to the workflow

Branching is most trustworthy when each possible path has been checked intentionally.