Workflow filters

A Filter step protects downstream Actions by allowing a route to continue only when its rules match. Workflow Filters are evaluated against the Trigger, the Step's primary input, and outputs from earlier Steps available on the same lineage.

Add a Filter

1. Select an add point before the Action you want to protect.
2. Choose Filter.
3. Select a field from the Trigger or an earlier Step.
4. Choose an operator.
5. Enter a fixed comparison value or select another available field.
6. Test representative JSON in the editor.
7. Save the Step and verify both a matching and non-matching run.

Rule groups

Conditions inside one group use AND: every condition must match. Multiple groups use OR: the Filter continues when any complete group matches.

(status = "paid" AND total >= 100)
OR
(customer.tier = "enterprise")

Operators

The Workflow runtime supports:

• Presence: exists, does not exist.
• Boolean: is true, is false.
• Equality: exactly matches, does not exactly match.
• Text: contains, does not contain, starts with, does not start with, ends with, does not end with.
• Membership: in, not in.
• Number: equals, not equals, greater than, greater than or equal, less than, less than or equal.
• Date: after, before, equals.

Numeric comparison accepts finite numbers and numeric strings. Date comparison parses both values as dates. Invalid numeric or date values do not match.

Fixed value versus field value

Use a fixed value for a business rule such as total >= 100. Use another field when two parts of the event must agree, such as billing.country exactly matches shipping.country.

Runtime outcomes

• A match continues on the normal route and passes the input through unchanged.
• A non-match selects the filtered outcome; normal downstream Steps are skipped.
• An invalid Filter configuration produces an error outcome.

Use a Paths step instead when different conditions should lead to different Actions rather than simply continuing or stopping.

Common mistakes

• Combining alternatives in one group when separate OR groups are needed.
• Comparing a number as free-form text without checking the actual provider payload type.
• Selecting a field from an unrelated parallel branch.
• Assuming a sample field is always present in real provider events.
• Testing only the passing case and never confirming the protected Action is skipped.

Use Workflow Audit to inspect the selected route and downstream skipped Steps.