Investigation Flows

Investigation Flows

Since IRIS-NG-v2.0.0, an investigation flow is a named checklist with ordered steps that attaches itself to alerts or clusters at ingest, so the analyst who opens an alert finds the checklist already there. Flows exist to make sure the obvious things happen on every alert of a given kind — not to gate anyone.

Defining a flow

Flows live at Settings → Investigation flows. A flow is:

• Ordered steps, each optionally marked required.
• Conditions deciding what it attaches to — the same condition builder clustering rules use, over the alert's fields.
• A target: alerts, clusters, or both.

Targeting semantics are worth knowing precisely:

• An alert-targeted flow attaches to every matching alert.
• A cluster-targeted flow attaches once per cluster, at the moment the cluster is created — evaluated against the alert that created it — not once per member alert. A checklist about "this activity" appears once, not forty times.

Attachment is idempotent: re-ingesting or re-evaluating cannot attach the same flow to the same object twice.

Working a checklist

Checklists appear in the alert's own expanded view on the alerts page, and on a cluster's Summary tab.

• Steps are marked done or skipped, with an optional note, and a record of who did it and when.
• Incomplete required steps are surfaced as an advisory count. Nothing is blocked — an alert can be escalated or dismissed with required steps open; the count exists so that is a visible decision rather than an oversight.
• The section only renders when a flow is actually attached — no empty checklist scaffolding on unmatched alerts.

Editing a deployed flow

Editing preserves analyst progress. When you save changes to a flow, steps are matched by identity — renaming a step, reordering steps, or inserting new ones does not discard the done/skipped state anyone has recorded against the surviving steps. Deleting a step deletes its recorded state with it, which is the one destructive edit.

Deploy-time backfill

When a flow is created or its conditions change, existing clusters are evaluated for attachment using their earliest member alert as the trigger proxy — so a cluster-targeted flow written after the fact still lands on the activity it describes.

Notes

• Flow state lives with the alert or cluster it is attached to; there is no separate "flow runs" page.
• Conditions evaluate the triggering alert. A cluster has no field values of its own to match on — which is exactly why cluster-targeted flows evaluate the creating alert.
• The API is additive under /api/v2/ (API Reference).