---
title: 'Filter'
description: 'Continues or drops execution based on a value comparison.'
---
# Filter

Evaluates a comparison and sends execution to one of two outgoing handles:

- **Passed** — the condition was true, continue downstream.
- **Dropped** — the condition was false; this branch terminates.

Unlike **If/Else**, Filter's semantic is "should this item continue?" rather
than "which of two paths?" — the `dropped` branch is usually not wired to
anything (the branch just ends).

## When to use

- Inside a **Loop** to skip items that don't meet criteria ("Only include
  transactions over $10.")
- Early-exit branches that should stop if a precondition fails.
- Any "continue only if" gating.

## Configuration

| Field | Required | What it does |
|---|---|---|
| `field` | Yes | The value to evaluate. Supports `{{...}}`. |
| `operator` | Yes | Comparison operator. |
| `value` | — | What to compare against. Required except for `exists`. |

### Available operators

`eq`, `neq`, `gt`, `lt`, `gte`, `lte`, `contains`, `startsWith`, `endsWith`,
`exists`.

Filter has two extra operators vs If/Else — `startsWith` and `endsWith` —
handy for string-based filtering ("Skip emails ending in @internal.com").

## What it outputs

Nothing is written to the context. Execution is routed to `passed` or
`dropped`; the downstream nodes read from the *upstream* nodes, not from
Filter.

## Gotchas

- **Dropped branch**: if you wire the `dropped` handle to something, it
  runs on dropped items — useful for "log what we skipped" patterns.
  Most workflows leave it unwired.
- **Inside a Loop**: drops skip the current iteration only; the loop
  continues with the next item. `failedCount` on the Loop output does
  NOT include filtered-out items.