> For the complete documentation index, see [llms.txt](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/operate/workflows/conditions.md). # Conditions How conditions filter a trigger's events down to the ones worth acting on — filter types and operators, the triggers that require a condition, and the full set of filters available for each trigger. Conditions decide **which** of a trigger's events are worth acting on. A "New Finding Detected" trigger fires constantly; conditions are how you say *"…but only the critical ones, on a Tier 1 service, that have a fix."* Without them, a busy trigger would fire its actions on everything.

The Condition step of the builder: a Filter set to Auto-Fixable, an Operator of Is, and a Value of True, with a padlock icon and an Add Filter button. — A condition is a Filter, an Operator, and a Value. The padlock marks a filter an action locked on for you.

{% hint style="info" %} **Conditions vs. data elements.** Conditions are what you *filter on* — the fields Heeler evaluates to decide whether to act. [Workflow data elements](/mrecEO40m5D6bt7Pq5pE/reference/workflow-trigger-data-elements.md) are what you *print* — the values you insert into a message, ticket, or webhook. Same trigger data, two different jobs. {% endhint %} ## How a condition is built Each condition is a row with three parts — a **Filter** (what to look at), an **Operator** (how to compare), and a **Value**. Add as many as you like with **Add Filter**; they're combined with **AND**, so an event has to satisfy *every* condition to proceed. Values *within* a single multi-select filter are OR'd, so "CVSS Severity is one of Critical, High" matches either. Add no conditions — or the catch-all **Accept All** filter — and the workflow fires on every event the trigger produces. The operators you get depend on the filter's type:

Filter type	Operators	What it's for
Multi-select	`in`, `not in`	Pick one or more values from a fixed or data-driven list.
Integer	`==` `!=` `<` `<=` `>` `>=`	Whole-number comparison (some filters restrict this — for example a "days" filter may allow only `<=` and `==`).
Float	`==` `!=` `<` `<=` `>` `>=`	Decimal comparison, e.g. a CVSS or EPSS score.
Boolean	`==`, `!=`	A true/false toggle.
String	`==`, `!=`	Exact text match, e.g. a package name or vulnerability ID.
No input	—	Evaluated on its own as a yes/no — no value to enter (e.g. "SLO Past Due").
JQ (Advanced)	—	A raw JQ expression plus the value you expect it to produce. For cases the built-in filters can't express.

{% hint style="warning" %} Workflows that use a **JQ (Advanced)** filter can't be [run in batch](/mrecEO40m5D6bt7Pq5pE/operate/workflows/execution-and-management.md#running-a-workflow-on-demand) — JQ is evaluated per event, not translated into a bulk query. {% endhint %} ## Required conditions Two triggers won't save until you add at least one condition from a specific set — otherwise they'd fire on an unbounded stream of "approaching" dates:

Trigger	Needs at least one of
SLO Expiring	SLO Due Within (Days) · SLO Past Due · SAST SLO Due Within (Days) · SAST SLO Past Due
Finding Override Expiration	SLO Override Due In (Days) · SLO Override Past Due · Risk Override Expires In (Days) · Risk Override Expired

## Conditions an action sets for you Some actions add and lock a condition automatically, because they only make sense for certain events. Adding the **Fix with Heeler Agent** action locks an **Auto-Fixable is True** condition (the padlock in the screenshot above) and limits the **Fixability** filter to the tiers the agent can handle — the agent only acts on findings it can generate and validate a fix for. You can still add your own conditions alongside it. ## Available filters by trigger The filters offered depend on the trigger. The groups below list what each surfaces, with exact values for the fixed-choice filters. Filters marked *data-driven* populate from your own environment (your repositories, teams, rules, and so on). ### Finding and vulnerability filters *Apply to: New Finding Detected, New Finding Override, New Finding Fix Available, Finding Override Expiration, SLO Expiring.*

Filter	Type	Values / notes
CVSS Severity	Multi-select	Critical, High, Medium, Low
CVSS Score	Float	0–10
Exploit Status	Multi-select	Likely Not Exploited, Possibly Exploited, Actively Exploited
Heeler Risk	Multi-select	Defer, Plan, Urgent
Fix Available	Boolean
Package Ecosystem	Multi-select	Your dependency ecosystems
SLO Override Reason	Multi-select	No Fix Available, Fix Complexity, Not a Priority, Other (New Finding Fix Available only)

### Remediation filters *Apply to: New Remediation Available.*

Filter	Type	Values / notes
CVSS Severity	Multi-select	Critical, High, Medium, Low, None
CVSS Severity (most severe)	Integer	Critical, High, Medium, Low, None, ordered highest to lowest. Operators `==` `!=` `<` `<=` `>` `>=`
CVSS Score	Float	0–10
EPSS	Float	Exploit-prediction score
Exploit Threat	Multi-select	Likely Not Exploited, Possibly Exploited, Actively Exploited
Heeler Risk	Multi-select	Defer, Plan, Urgent
Solution Type	Multi-select	Specific Version, Version Range, No Fix Available, Deprecated Package, Migrate Package
Fixability	Multi-select	Easy, Medium, Hard, Unknown
Auto-Fixable	Boolean	Locked to `True` when the Fix with Heeler Agent action is used
Direct Dependency	Boolean
Package Name	String	Exact match
Vulnerability ID	String	Exact match (CVE, GHSA, PYSEC, …)

#### Choosing between the two severity filters A remediation covers several findings at once, and the two severity filters read that set differently. | Filter | What it tests | | ------------------------------- | ---------------------------------------------------------------------------------- | | **CVSS Severity** | Whether *any* finding on the remediation has one of the selected severities | | **CVSS Severity (most severe)** | The severity of the remediation's most severe active finding, as one ordered value | A remediation carrying a Critical finding and a Low finding matches **CVSS Severity** under Critical and under Low. Two workflows built as complementary branches on that filter both fire on it. **CVSS Severity (most severe)** gives one value per remediation, so a comparison splits the set with no overlap. Use it to send `>= High` remediations down one path and `< High` remediations down another, with each remediation taking exactly one path. ### SAST finding filters *Apply to: New SAST Finding Detected. (SLO Expiring adds SAST SLO Due Within (Days) and SAST SLO Past Due; New Finding Override adds SAST SLO Override Reason.)*

Filter	Type	Values / notes
Severity	Multi-select	Critical, High, Medium, Low, Info
Confidence	Multi-select	High, Medium, Low, Unknown
Rule	Multi-select	Data-driven
Category	Multi-select	Data-driven
Finding Lane	Multi-select	Indicator of Compromise, Vulnerability (CWE), Supply Chain, Code Quality — act on a whole class of finding without naming rules one at a time

### Secret filters *Apply to: New Secret Detected.*

Filter	Type	Values
Secret Validation Status	Multi-select	Rotate Now, Rotate, Triage, No Action, Expected. Each value selects the underlying statuses in that action bucket.
Secret Confidence	Multi-select	High, Medium, Low, Unknown
Secret Visibility in Default Branch	Multi-select	Visible in Default Branch, Not Visible in Default Branch

### License violation filters *Apply to: Dependency License Violation.*

Filter	Type
Dependency Active	Boolean
Direct Dependency	Boolean

### Agent file filters *Apply to: New At-Risk Agent File Detected.*

Filter	Type	Values
Assessed Intent	Multi-select	Malicious, Suspicious, Benign

### Guardrail filters *Apply to: PR Merged with Unresolved Guardrail Violations.*

Filter	Type	Values / notes
Guardrail Action Level	Multi-select	Block, Warn
Guardrail Rule	Multi-select	Data-driven
CVSS Severity	Multi-select	Critical, High, Medium, Low
Base Branch	Multi-select	Data-driven
SCM Provider	Multi-select	GitHub, GitLab, Bitbucket
Contributor	Multi-select	Data-driven
Branch Protection Circumvented	Boolean

### SLO and override timing filters *The "days"/"past due" filters used by the SLO Expiring and override-expiration triggers (see* [*Required conditions*](#required-conditions)*).*

Filter	Type	Notes
SLO Due Within (Days)	Integer	Operators `<=`, `==`
SLO Past Due	No input	Fires once the SLO is past due
SAST SLO Due Within (Days)	Integer	Operators `<=`, `==`
SAST SLO Past Due	No input
SLO Override Due In (Days)	Integer	Operator `==`
SLO Override Past Due	No input
Risk Override Expires In (Days)	Integer	Operator `==`
Risk Override Expired	No input

### Behavioral detection filters *Apply to: New Behavioral Detection.*

Filter	Type	Values / notes
Detection Query	Multi-select	Which checks to act on, by name — Activity from unapproved country, Rapid repository cloning, Protected branch policy overridden, and the rest of the catalog
Detection Severity	Multi-select	Critical, High, Medium, Low, Info — informational detections such as an agent-created pull request are selectable, so a workflow can carry them or leave them out

### Repository and ownership filters Available on most triggers to scope by where the event happened or who owns it:

Filter	Scope
Repository	All triggers except New Repository Discovered and Repository Deleted
Starred Repository	All triggers except New Repository Discovered and Repository Deleted
Package Name / Vulnerability ID	All triggers except New Repository Discovered and Repository Deleted
Tech Lead · Security Lead · Team · Sub-Group	All triggers (Sub-Group applies to GitLab groups)
Application	All triggers except New Repository Discovered and Repository Deleted — application membership is a property of the repository, so it is offered wherever the repository is known, not only on finding triggers
Source · Organization / Group	New Repository Discovered, Repository Deleted, and Repository Renamed only

### Advanced

Filter	Type	Notes
Accept All	No input	Always matches — use it to fire on every event.
JQ Filter (Advanced)	String	A raw JQ expression and the expected value. Blocks batch runs.

## Related * [Triggers](/mrecEO40m5D6bt7Pq5pE/operate/workflows/triggers.md) — the events these conditions filter. * [Actions](/mrecEO40m5D6bt7Pq5pE/operate/workflows/actions.md) — what runs once conditions are met. * [Workflow Trigger Data Elements](/mrecEO40m5D6bt7Pq5pE/reference/workflow-trigger-data-elements.md) — the full field set behind these filters. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/operate/workflows/conditions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.