Workflow stages
The state machine that takes an alert from inbox to closed case.
This is the developer-oriented mirror of the workflow product page. Same four stages, with the explicit state transitions and the API endpoints involved.
1. Ingest
Entry: POST /api/v1/alerts.
States: new → deduplicated | suppressed | triage.
newis transient - only exists while normalisation runs.deduplicatedmeans an existing alert with the same content hash absorbed this one. The original gets arepeat_countbump.suppressedmeans an active suppression rule killed it. Logged but not queued.triageis the queue analysts see.
2. Triage
Entry: alert in triage.
Actions:
POST /alerts/{id}/dismiss→ statedismissed, requiresreason_code.POST /alerts/{id}/link→ statelinked, attached to a case.POST /alerts/{id}/escalate→ stateescalated, new case created.
Bulk endpoints exist on all three for queue-cleaning workflows.
3. Investigate
Entry: case in open.
States: open → investigating → contained → eradicated → recovered.
State transitions are explicit via POST /cases/{id}/transition. Skipping is allowed (e.g. open → recovered for benign verdicts) but logged.
SLA timers tick per severity. Breach generates an event in the timeline and (if configured) a webhook.
4. Resolve
Entry: case in any terminal-eligible state.
Action: POST /cases/{id}/resolve with a verdict and root cause.
Side-effects:
- Markdown + PDF report generated, attached to the case.
- Outbound webhook
case.resolvedfires. - Confirmed-bad observables flagged for TI export.
- Case becomes read-only except for the audit-log-only reopen action.
State diagram
┌──── deduplicated
│
ingest ──┤
├──── suppressed
│
└──── triage ──┬── dismissed
│
├── linked ──┐
│ ├─► case: open ─► investigating
└── escalated ┘ │
▼
contained
│
▼
eradicated
│
▼
recovered
│
▼
resolved (verdict + report)