Dark mode
Flow filters and conditions

Flow filters and conditions

Filters decide which events a flow reacts to. Without them, a flow could run far more often than you want, for example on every push to every repository. This page lists the filters for each trigger and explains optional semantic conditions.

Filters appear in the flow editor as if and and rows under When. Only the filters that apply to your trigger are shown.

Filters by trigger

Trigger

Filters

What you must set

Task enters a workflow state

Workflow, state

Both

Interactive run is approved

Workflow, state

Both

GitHub or GitLab push

Repository, branch

A repository or a branch

GitHub pull request or GitLab merge request opens, merges or closes without merging; GitHub review is requested

Repository, base branch

A repository or a base branch

GitHub or GitLab release publishes

Repository, tag

A repository or a tag

GitHub check suite completes, GitLab pipeline completes

Repository, branch, conclusion

At least one of the three

Schedule ticks

Schedule

A schedule

If a required filter is missing, Create flow stays disabled and its tooltip tells you what to add, such as Add a repository or base branch filter.

How filters match

  • Repository – choose a connected repository, or choose any / custom… and type owner/repo. Leave it empty to match any repository.

  • Branch and base branch – must match the branch name exactly, such as main. Leave empty for any branch.

  • Tag – must match the release tag exactly, such as v1.0.0.

  • Conclusionsuccess, failure, cancelled or timed out.

  • Workflow and state – the flow runs when a task in that workflow enters that state.

All filters you set must match for the flow to run.

Semantic conditions

A semantic condition is an optional plain-language check, for example The task describes a customer-facing bug. Helpin uses AI to compare the event with your condition before running the action.

  1. In the flow editor, find Semantic condition (optional).

  2. Describe the events you want, in up to 500 characters.

  3. Save the flow.

How it works:

  • Helpin checks the event details and, when available, the task title and description.

  • The action runs only when the condition clearly matches. If the result is uncertain, or the check can't run, Helpin skips the action.

  • Every check is recorded in Activity, with results such as Condition matched — action may proceed or Condition did not match — action skipped.

  • Semantic conditions only work with event triggers. Remove the condition before switching a flow to Schedule ticks.

If the field is unavailable, it explains why. Most often, semantic conditions haven't been enabled for your workspace; ask your administrator.

Tips

  • Start narrow. Add a repository and branch filter first, then widen the flow once you're happy with the results.

  • Use semantic conditions to separate events that look the same, such as bug reports versus feature requests entering the same state.

  • Check Activity for skipped runs if a flow runs less often than you expect.

Was this article helpful?