Filters, Branching, and Conditional Logic

Conditional automations with filters

Most useful automations shouldn't run every step every time. You want the VIP treatment only for high‑value orders, the escalation only for breached SLAs, the reminder only for carts above a threshold. In StretchAutomate you express that with filter steps and dependencies — together they give you branching and conditional logic without a separate "if/else" concept to learn.

How a filter behaves

A filter is a gate step (type filter, from the Built‑in logic connector). During a run the engine evaluates the filter's rules against the run context:

• If the rules pass, the filter is recorded succeeded and execution continues to the steps that depend on it.
• If the rules do not pass, the filter is recorded skipped — and here is the key behavior: every step that depends on the filter (directly or transitively) is also skipped, each recorded with the reason "upstream step skipped."

This skip propagation is what turns a single filter into a branch gate. Everything downstream of a filter forms a conditional branch that runs only when the filter passes.

Designing a branch

1. Add a filter step with a clear key (e.g. is_high_value) and its rule(s).
2. Give every step that belongs to the conditional branch a depends_on that includes the filter's key.
3. Leave steps that should run regardless of the condition depending only on the trigger (or on a different, unconditional step).
4. Validate and read the plan: the gated steps should appear in stages after the filter, confirming they sit behind the gate.
5. Simulate both cases — one payload that passes the filter and one that fails — and read the ledger to confirm the branch runs or skips exactly as intended.

Multiple and nested branches

Because steps form a DAG, you can build richer logic:

• Parallel gated steps — several steps that all depend on the same filter run together (in the same stage) when it passes.
• Independent branches — two different filters, each gating its own set of steps, let one condition trigger one path and another condition trigger a different path.
• Nested conditions — a step under filter A can itself be a filter B; steps under B run only when both A and B pass, since a skip at A propagates through B.

There is no explicit "else" branch; to handle the negative case, use a second filter with the opposite rule gating an alternative branch.

Realistic example

An order workflow triggered by StretchShop order_created needs VIP handling for big orders and a standard thank‑you for everyone:

• big_order — a filter that passes when {{ trigger.total }} exceeds 500.
• vip_tag — StretchCRM tag_customer, depends_on big_order.
• account_manager_task — StretchTasks create_task, depends_on big_order.
• thank_you — StretchMail send_email, depends_on the trigger only (runs for every order).

Simulating a $250 order: big_order is skipped, so vip_tag and account_manager_task are skipped (upstream step skipped), while thank_you still runs. Simulating a $900 order: big_order succeeds, and both VIP steps run in the same stage alongside the thank‑you. One filter cleanly gates a two‑step branch.

Tips

• Gate early. Put the filter as far upstream as possible so its skip propagation guards the whole branch in one place.
• Simulate the failing case, not just the passing one — confirming steps don't run is as important as confirming they do.
• For an if/else shape, use two opposite filters, each gating its own branch.
• Keep steps that must always run off the trigger (or off an unconditional step) so a filter never accidentally skips them.

Troubleshooting

A step ran that I expected the filter to block. That step doesn't actually depend on the filter. Add the filter's key to its depends_on so skip propagation reaches it.

The whole branch skipped unexpectedly. The filter's rules evaluated to not passed. Open the run in the ledger — the filter step shows the rules it evaluated. Adjust the rule or the data it reads.

Everything downstream skipped after an early step. A skip propagates down the entire branch. Find the first skipped step in the ledger trace — it's the filter (or upstream skip) that gated the rest.