Filters and branches

Most automations shouldn't run every step every time. Filters decide whether a path continues. Branches split the automation into several paths, each evaluated on its own.

The short version: use a filter for a yes-or-no gate on one path. Use a branch when one event should produce different outcomes depending on the data.

What does a filter do?

A filter checks conditions against data from earlier steps. If they pass, everything after it runs. If they don't, that path simply stops.

A stopped run is not a failure. It ran, evaluated the conditions, found nothing to do, and ended cleanly — that's the normal outcome for most events in a well-filtered automation.

What conditions can I check?

Operator	Continues when
equals	The value matches exactly
not equals	The value does not match
contains	The text contains the value
not contains	The text does not contain the value
has item	A list contains the value

Conditions combine with AND (all must pass) or OR (any must pass).

has item is the one for list data — checking whether an order's line items include a particular product, for example, rather than comparing a single value.

Where should a filter go?

As early as possible. Every step after a filter only runs when it passes, so filtering first avoids doing work you're going to throw away — and that includes waiting, if there's a delay further down.

Better still, some triggers accept scope filters of their own: restrict to one form rather than every form, for instance. Where that's available, prefer it. The automation then never starts at all for events you don't want, instead of starting and stopping one step in.

Use a filter node for anything that depends on the payload itself — the order total, the status, the answer someone gave.

What does a branch do?

A branch splits the automation into multiple paths. Each path has its own conditions deciding whether it runs, and its own steps.

Use it when the same event should lead to different work. A single order might go one way if it's above €500 and another way otherwise; a subscription event might route differently per plan.

Filter or branch?

Ask whether you need one outcome or several:

• One outcome, conditionally → filter. "Only do this for completed orders."
• Several outcomes, by data → branch. "High-value orders go to the sales team, everything else to the standard flow."

A branch without alternatives is just a filter with extra structure, so don't reach for it unless there's genuinely more than one path.

A worked example

Routing form submissions by budget:

1. Trigger — Form submitted in Gravity Forms
2. Branch
   • Path A — filter: budget field equals "over 10k" → create a deal and notify the sales channel
   • Path B — filter: budget field not equals "over 10k" → add to the nurture list

Both paths see the same submission data. Each evaluates its own conditions and runs its own steps.

What if no path matches?

Nothing happens, and the run ends without error. If you want a catch-all, give one path conditions that are always true and put it last in your thinking — there's no automatic "else".