Skip to main content

Decision

Use the Decision step to branch a flow into two paths based on a condition. When the step runs, AutoFlow evaluates the condition and continues along the Yes edge or the No edge. It is the right tool whenever a downstream step should only run for some inputs.

Typical use cases include:

  • Filtering before expensive work. Skip the rest of the flow when an inbound payload is missing required fields.
  • Routing by state. Run different actions for posted vs. open documents, internal vs. external customers, or success vs. failure outcomes.
  • Guarding side effects. Only send an email when the previous step actually changed something.

Configure the step​

Open the flow editor, add Decision, and fill in the configuration card.

Description​

  • Purpose: Make the branch's intent clear at a glance.
  • When to fill it: Always. The description is shown in the editor and execution history.
  • Tips: State the question, for example, Is the customer blocked? or HTTP request succeeded?

True label​

  • Purpose: The label rendered on the Yes edge in the flow graph.
  • When to fill it: Optional. Defaults to Yes.
  • Tips: Use a label that reads well in context, for example, Posted / Open, Internal / External, or Above limit / Within limit.

False label​

  • Purpose: The label rendered on the No edge in the flow graph.
  • When to fill it: Optional. Defaults to No.
  • Tips: Mirror the True label so the graph reads naturally — same axis, opposite values.

Condition​

  • Purpose: The expression AutoFlow evaluates to pick the path.
  • When to fill it: Required. Use a SmartFilter expression that resolves to a boolean – for example, {{httpRequest.statusCode}} = 200 or {{customer.blocked}} != ''.
  • Tips: Reference outputs from previous steps via SmartField tokens ({{stepName.field}}). The full operator set – =, !=, >, <, >=, <=, ~, ^=, $=, plus & / | / ! / ( ) for combining – is documented on the SmartFilters & SmartFormulas page.

Behavior​

When this step runs:

  • AutoFlow evaluates the configured condition.
  • The result (true or false) is added as the step output result.
  • The flow continues along the matching edge — True if the condition is true, False otherwise.

The Decision step has exactly two outgoing edges. They are required: a flow with an unconnected edge is invalid.

Best practices​

  • Keep conditions short. If the expression grows beyond one line, push the work into a Parser step that produces a clean boolean SmartField, and let Decision read that field.
  • Use Decision for control flow, not error handling. When you want to react to a step failing, configure the step's On Error handling — Decision is for value-based branching, not for catching errors.
  • Label both edges. Default Yes / No is fine for binary checks, but real-world branches read better with the actual values (for example, Found / Not found).