Case Management, Alert Triage, and Automated Response Workflows
Triage mechanics
Alerts arrive in the Alerts table with rule name, severity, risk score, and status. Status moves through open → acknowledged → closed, and closing requires a reason (for example duplicate, false positive, true positive, benign). Assignees and tags track ownership. The alert details flyout is the action hub: investigate in Timeline, add to an existing or new case, add a rule exception directly from the alert, and run response actions such as host isolation, process termination, or an Osquery live query. Severity and risk score are distinct: severity is a rule-level label; risk score is a numeric contribution used in risk-based alerting and entity risk scoring. Changing an alert's status does not change the rule or prevent future alerts - use an exception for that.
Cases
Cases group alerts and free-text investigation notes into a tracked record with status, severity, assignees, tags, custom fields, and comments. Case templates standardize those fields. Connectors push cases outward to ticketing or chat systems (ServiceNow, Jira, Swimlane, Slack, webhooks), while case analytics summarize volume. Note that Cases in current versions are shared rather than space-siloed, unlike rules and alerts.
Automation
Rule actions fire through connectors: Slack/Teams notifications, webhook calls, Jira or ServiceNow ticket creation, email, PagerDuty. Response actions on endpoints (isolate host, kill process, get process memory on Windows) require Elastic Defend on the host and appear in the response actions history. Osquery-based rules can attach automated live queries in newer versions; whether an action may be automated depends on rule type and integration, so verify rather than assume.
Rule of thumb: if the same alert recurs and is genuinely benign, add an exception; if it deserves follow-up, attach to a case; if a host is compromised, isolate first, then document in the case.