Automation rules and proposals
What runs on incident create and update, the seven action types, the precise conditions under which a playbook actually fires versus only ever proposing one, and the proposals queue.
An automation rule watches for something to happen to an incident and, if your conditions match, runs a fixed list of actions in order. This article covers what triggers a rule, how a condition is written, exactly what each of the seven action types does — including two with real caveats worth reading carefully — and the pending-proposals queue that stands in whenever an action cannot run unattended.
The three trigger types
| Trigger | Status |
|---|---|
incident_created | Wired end to end — but only for incidents a scheduled rule opens. There is no POST /siem-incidents endpoint today, so a manually opened incident, or one a future producer creates, does not yet call this trigger. The shape of the fix (the same kind of seam incident_updated uses) is established; the second call site has not been added. |
incident_updated | Wired end to end. Fires after a real mutation — status, severity, assignee or tags — from the incident Patch endpoint. An empty or unrecognised-field patch does not fire it, matching incident_created's discipline of only firing on a genuine change. |
alert_created | Same underlying engine and schema as the other two. Nothing in the platform calls it yet — no producer fires this trigger today. |
How a condition is structured
A condition is field, operator, value — the same three-part shape as the classic search DSL, deliberately, so that a future upgrade to richer condition matching is a parser change rather than a schema change. Conditions on one rule are combined with AND only; there is no OR and no grouping today.
The seven action types
| Action | What it does |
|---|---|
notify | Wired to the real delivery outbox — the same durable, retrying dispatch mechanism your SIEM alerts and saved-search alerts already use. It goes to whichever destinations your tenant's own routing already sends to: Slack, Teams, PagerDuty, Jira, ServiceNow, a generic webhook, or email. There is nothing new to configure here beyond your existing delivery routing. |
assign | Real. Sets the incident's assignee. |
tag | Real. Adds a tag to the incident. |
close | Real. Changes the incident's status. |
enrich | Real. Looks the incident's entities up against your configured lookups (watchlists) and, when the rule fires in the live API process, against your configured external threat-intel providers too — see External threat-intel enrichment for the precise reachability caveat. |
create_ticket | Not wired. See the explanation below — this is a stated architecture gap, not a missing button. |
run_playbook | Conditionally real. See the autonomy section below — this is the one that most needs reading carefully before you rely on it. |
Why create_ticket is not wired
This is a real, documented gap, not an oversight. create_ticket needs to return a ticket reference synchronously — the calling code needs the ticket key back in the same request, so it can be linked to the incident. Your existing ticket integrations (Jira, ServiceNow) do not work that way: they write to the same durable delivery outbox notify uses, and a worker dispatches the write later, asynchronously. No ticket key comes back to the caller.
Wiring create_ticket correctly means one of two things: a direct, synchronous call to Jira or ServiceNow that bypasses the outbox's retry, redaction and rate-limit handling entirely — which duplicates that machinery rather than reusing it, the opposite of how every other action here is built — or extending the outbox itself to support a synchronous request/reply round trip, which is new design work, not a wiring task. Neither has been done. create_ticket is left as a documented gap rather than forced through with either shortcut.
run_playbook and the autonomy ladder
run_playbook is the action most worth understanding precisely, because whether it actually executes anything depends on where the automation rule fires from — and that is not something the rule itself controls.
| Where the rule fires | What happens |
|---|---|
| A human approves a pending Proposal | The playbook runs immediately, with the approving human recorded as the requester. The human's approval is the autonomy check at that point — there is no separate autonomy-switch gate on an approved proposal. |
| The rule fires live in the API process, with the tenant's autonomy switch already on | The playbook runs immediately, gated by the same tenant autonomy switch that governs autonomous response everywhere else in the product — see Autonomy tiers explained and Stopping autonomous response. |
| The rule fires from the background worker process — which is what runs scheduled-rule detections | The playbook never runs automatically. The worker process does not carry the playbook engine at all — it was not wired into that process this wave — so there is no approval surface and no executor available to it. A run_playbook action firing from the worker always creates a Proposal for a human to approve instead, rather than either running unattended from a process with nothing to check it, or silently dropping the action. |
The pending-proposals queue
Whenever an action cannot run unattended — a blocked run_playbook, per the table above — a Proposal is created instead of the action being skipped or silently failing. SIEM → Automation rules (/siem/automation-rules) lists your rules and, below them, a pending-proposals queue with Approve and Dismiss controls. Approving one executes the underlying action (for run_playbook, this is the human-approval path from the table above); dismissing it discards the proposal without acting.
In the console
The create-rule modal lets you name a rule, choose its trigger, build conditions field by field, and choose an ordered list of actions. It is read-only after creation.
Also not built: a dry-run preview against recent incidents, and run history beyond the proposals queue — Run rows are recorded internally for every rule firing, but there is no endpoint that lists them back to you.
What to read next
- How alerts are grouped into incidents — what an automation rule is actually reacting to.
- External threat-intel enrichment — the precise reachability limits on the
enrichaction's external lookups. - Autonomy tiers explained — the switch that gates a live-fired
run_playbook.