Description
What: In 9.6, Cases adds a Tech Preview capability for analysts to run workflows without leaving the case context.
Users can open a searchable workflow picker and start a workflow from:
- a case detail page
- a row or bulk action on the cases list (one workflow execution for 1–10 selected cases)
- an alert attached to a Security case, including selected alerts
- an individual case observable or selected observables
If the workflow requires manual inputs, the picker prompts for them before starting the run. The server validates the selected cases and contextual items before execution.
Each run is recorded in the case Activity log with the initiating user, workflow name, timestamp, and the context it ran against. Users with permission to view workflow executions also get a link to the execution details. Runs are also written to the audit log.
Administrators can optionally configure Available workflow tags in Case settings. When tags are configured, Cases workflow pickers show only workflows matching at least one selected tag. When the setting is empty, all workflows are available.
Access requires:
- an appropriate subscription (Enterprise or trial for self-managed deployments)
- Workflows to be available and enabled
- permission to execute workflows
- permission to update every case included in the run
The Run workflow action is hidden when these requirements are not met. The feature is enabled by default and can be disabled with the Cases run-workflows feature flag.
The related Tech Preview cases.observablesAdded trigger should also be documented. It starts a workflow after new observables are persisted to a case and supplies the case ID, owner, and newly added observable details. Include loop-prevention guidance for workflows that add observables themselves.
When: Planned for Elastic Stack 9.6. The exact Serverless production promotion date is still to be confirmed.
Why: Analysts currently have to leave a case to run response or enrichment automation and then manually record what happened. Running workflows in context reduces response time and context switching while creating an auditable record of who initiated each action and what it targeted.
Documentation should cover the entry points, the 10-case selection limit and single-execution behavior, permissions and subscription requirements, Activity log and execution links, workflow-tag filtering, Tech Preview status, and the cases.observablesAdded trigger.
Resources
Which deployment methods does this change impact?
Elastic On-Prem and Cloud (all)
Feature differences
No user-facing behavior differences are planned between supported deployment methods. Availability still depends on Workflows support, the required subscription or feature tier, and the user's Cases and Workflows permissions. The exact Serverless production promotion date is still to be confirmed.
What Elastic Stack release is this request related to?
9.6
Serverless release
Targeting the 9.6 timeframe; exact production promotion date TBD.
Collaboration model
We expect to collaborate on the first draft
Point of contact.
Main contact: @kelvtanv
Stakeholders: @melissaburpo @cthulhusec
Description
What: In 9.6, Cases adds a Tech Preview capability for analysts to run workflows without leaving the case context.
Users can open a searchable workflow picker and start a workflow from:
If the workflow requires manual inputs, the picker prompts for them before starting the run. The server validates the selected cases and contextual items before execution.
Each run is recorded in the case Activity log with the initiating user, workflow name, timestamp, and the context it ran against. Users with permission to view workflow executions also get a link to the execution details. Runs are also written to the audit log.
Administrators can optionally configure Available workflow tags in Case settings. When tags are configured, Cases workflow pickers show only workflows matching at least one selected tag. When the setting is empty, all workflows are available.
Access requires:
The Run workflow action is hidden when these requirements are not met. The feature is enabled by default and can be disabled with the Cases run-workflows feature flag.
The related Tech Preview
cases.observablesAddedtrigger should also be documented. It starts a workflow after new observables are persisted to a case and supplies the case ID, owner, and newly added observable details. Include loop-prevention guidance for workflows that add observables themselves.When: Planned for Elastic Stack 9.6. The exact Serverless production promotion date is still to be confirmed.
Why: Analysts currently have to leave a case to run response or enrichment automation and then manually record what happened. Running workflows in context reduces response time and context switching while creating an auditable record of who initiated each action and what it targeted.
Documentation should cover the entry points, the 10-case selection limit and single-execution behavior, permissions and subscription requirements, Activity log and execution links, workflow-tag filtering, Tech Preview status, and the
cases.observablesAddedtrigger.Resources
cases.observablesAddedtrigger: [Cases] Add cases.observablesAdded workflow trigger kibana#288224Which deployment methods does this change impact?
Elastic On-Prem and Cloud (all)
Feature differences
No user-facing behavior differences are planned between supported deployment methods. Availability still depends on Workflows support, the required subscription or feature tier, and the user's Cases and Workflows permissions. The exact Serverless production promotion date is still to be confirmed.
What Elastic Stack release is this request related to?
9.6
Serverless release
Targeting the 9.6 timeframe; exact production promotion date TBD.
Collaboration model
We expect to collaborate on the first draft
Point of contact.
Main contact: @kelvtanv
Stakeholders: @melissaburpo @cthulhusec