Enhancement: Easier Trigger Filter Testing in Workflows

:sparkles: Description

Workflows now makes trigger filters easier to use with confidence: you get warnings when a filter is missing, and a test experience that applies your trigger filter against your test input so you can see whether the filter matches before you enable the workflow.

:information_source: What You Need to Know

  • Optional today: Filters remain optional, but they are highly recommended.
  • Filter applied in test: Testing now applies your trigger filter against the test input and shows whether the filter matches. Previously, testing did not apply the trigger filter.
  • Scope: Not every trigger supports filters. This experience applies where filters are available.
  • Existing workflows: Enabled workflows keep running as they do today.
  • Coming later: We are also improving how you build trigger filters. More details in a future announcement.

:red_exclamation_mark: Problem

Writing JSONPath filters is challenging, and not everyone is an expert. Without clear guidance, filters get skipped or left too broad. It has also been hard to validate a filter in test, because testing did not apply the trigger filter the way a live run does. That leads to unintended executions and rate-limit risk.

:light_bulb: Solution

  1. Warnings: Missing-filter warnings in the workflow editor and on the Test Workflow experience when a filterable trigger has no filter
  2. Improved filter testing: Your trigger filter is applied during test against the test input, so you can see whether the filter matches

:people_hugging: Who is affected?

Authors of filterable event triggers in Identity Security Cloud Workflows.

Action required: None.
Action highly recommended: Add a meaningful filter on unfiltered event workflows and use the improved test experience before enable.

:spiral_calendar: Important dates

Sandbox (STG): August 24, 2026 · Production: August 31, 2026

:books: Where to learn more

1 Like

Hey @Takato,

I noticed that we regularly require a trigger to be: lifecycle state became X and identity attribute Y is A, B, or C. Y could be cost center, employee type etc.
Since the input of “LCS changed” does not contain information on Y, we can’t add it to the trigger and need to filter out those cases during the execution, but this means we get a lot of executions that are not really relevant.

It would be nice if we have the option to filter on random identity attributes in this trigger as well to prevent unneeded workflow executions.

1 Like