When an automation runs, a filter checks a condition and sends the contact down one of two paths: Yes (pass) or No (fail). But what happens if the contact's data changes between the time the filter runs and the time a later action executes?

Revalidation re-checks the filter condition before executing any downstream action, ensuring the contact still belongs on that path. It's enabled by default on all filters and is indicated by a shield icon on the filter in the canvas.

With revalidation on (default), the filter is re-checked before each downstream action runs. If the contact no longer matches, the remaining actions on that path are skipped.

With revalidation off, the filter result is locked in the moment it first runs. All downstream actions will execute regardless of whether the condition still holds.

Imagine this automation:

A contact enters the automation on Monday. The filter passes, Action 1 sends the welcome email, and the contact enters the 1-day wait. The next day (Tuesday), the automation resumes and is ready to execute Action 2.

With revalidation on: Before running Action 2, the filter re-checks: "Is it Monday?" It's Tuesday now, so Action 2 is skipped.

With revalidation off: The filter result was locked when it first passed on Monday. Action 2 executes on Tuesday regardless.

In most cases, you want revalidation on. But there are cases where locking the result makes sense:

Open any filter step in the automation builder. At the bottom, you'll find the Revalidation section with a toggle. When the toggle is on, the filter revalidates before each downstream action. When off, the result is locked.

Filters with revalidation enabled show a small shield icon on the canvas for easy identification.