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.Conclusion – success, 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.
In the flow editor, find Semantic condition (optional).
Describe the events you want, in up to 500 characters.
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.
Related articles
Was this article helpful?