Description
What: The Alert triggers page (explore-analyze/workflows/triggers/alert-triggers) tells users that a workflow receives "rich context data" through the event field when an alert fires — but never documents what that data actually contains. Users building workflows need to know which field paths are available so they can write template expressions like {{ event.kibana.alert.severity }} or {{ event.rule.name }}.
When: This is a gap in the current docs — no new feature needed, this is documentation of existing behavior.
Why: Without knowing the available fields, users are blocked from doing the core task the page is meant to enable: writing workflows that act on alert data. The problem is compounded because field availability varies by rule origin (Stack Management alerting rules, Security detection rules, Observability rules), and there is currently no guidance on those differences anywhere in the Workflows docs.
Resources
The page with the gap:
https://www.elastic.co/docs/explore-analyze/workflows/triggers/alert-triggers
Adjacent page confirming the event field exists but not documenting it:
https://www.elastic.co/docs/explore-analyze/workflows/triggers (see: "Alert: Complete alert data including fields, severity, and rule information")
Rule action variables reference (Stack alerting, Mustache — may inform Workflows field paths):
https://www.elastic.co/docs/explore-analyze/alerts-cases/alerts/rule-action-variables
Related: the alert index schema for .alerts-* indices likely defines the canonical field list for Security and Observability alerts. SMEs should confirm whether event.* in Workflows templates maps 1:1 to the alert document schema or is remapped by the workflow engine.
Proposed content additions (three sections):
- A self-serve escape hatch — a console step snippet users can add to log
{{ event | json:2 }} and inspect their own payload at runtime.
- A table of common fields present across all rule types (rule.id, rule.name, rule.type, kibana.alert.status, kibana.alert.start, kibana.alert.uuid, space_ids, tags).
- Per-origin field highlights for the fields distinctive to each rule type:
- Stack alerting: context.* (reason, value, threshold), kibana.alert.action_group
- Security detection rules: kibana.alert.original_event.*, risk_score, severity, rule.threat (MITRE), rule.type, workflow_status
- Observability rules: kibana.alert.evaluation.value, evaluation.threshold, group, reason
Which documentation set
Elastic On-Prem and Cloud (all)
Feature differences
Workflows and the underlying alerting systems exist across deployment methods. The field availability gap is consistent across all of them. However, SMEs should confirm whether Security detection rule fields differ between Serverless Security and stateful Security, as Serverless rules have some behavioral differences (e.g. API key model). The core event field structure is expected to be identical.
Release
N/A (documentation gap, not tied to a release)
Serverless release
N/A (this is a documentation gap fix for existing functionality, not a new feature launch)
Collaboration model
The documentation team
Point of contact
Main contact: @talboren
Stakeholders:
- Workflows engineering SME: Need help confirming
event field paths and whether they map 1:1 to the alert document schema
- Security detections dev: Need help validating Security-specific field list
- Observability Incident management dev: Need help validating Observability-specific field list
Description
What: The Alert triggers page (explore-analyze/workflows/triggers/alert-triggers) tells users that a workflow receives "rich context data" through the
eventfield when an alert fires — but never documents what that data actually contains. Users building workflows need to know which field paths are available so they can write template expressions like{{ event.kibana.alert.severity }}or{{ event.rule.name }}.When: This is a gap in the current docs — no new feature needed, this is documentation of existing behavior.
Why: Without knowing the available fields, users are blocked from doing the core task the page is meant to enable: writing workflows that act on alert data. The problem is compounded because field availability varies by rule origin (Stack Management alerting rules, Security detection rules, Observability rules), and there is currently no guidance on those differences anywhere in the Workflows docs.
Resources
The page with the gap:
https://www.elastic.co/docs/explore-analyze/workflows/triggers/alert-triggers
Adjacent page confirming the
eventfield exists but not documenting it:https://www.elastic.co/docs/explore-analyze/workflows/triggers (see: "Alert: Complete alert data including fields, severity, and rule information")
Rule action variables reference (Stack alerting, Mustache — may inform Workflows field paths):
https://www.elastic.co/docs/explore-analyze/alerts-cases/alerts/rule-action-variables
Related: the alert index schema for
.alerts-*indices likely defines the canonical field list for Security and Observability alerts. SMEs should confirm whetherevent.*in Workflows templates maps 1:1 to the alert document schema or is remapped by the workflow engine.Proposed content additions (three sections):
{{ event | json:2 }}and inspect their own payload at runtime.Which documentation set
Elastic On-Prem and Cloud (all)
Feature differences
Workflows and the underlying alerting systems exist across deployment methods. The field availability gap is consistent across all of them. However, SMEs should confirm whether Security detection rule fields differ between Serverless Security and stateful Security, as Serverless rules have some behavioral differences (e.g. API key model). The core
eventfield structure is expected to be identical.Release
N/A (documentation gap, not tied to a release)
Serverless release
N/A (this is a documentation gap fix for existing functionality, not a new feature launch)
Collaboration model
The documentation team
Point of contact
Main contact: @talboren
Stakeholders:
eventfield paths and whether they map 1:1 to the alert document schema