[Security][Cases][Workflows][9.6 & Serverless] Run workflows from cases #8148

Description

What: In 9.6 (Tech Preview), analysts can run workflows without leaving Cases. A workflow picker is available from multiple surfaces inside Cases. Each run is authorized against the selected cases, recorded in the case Activity log, and written to the audit log.

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, then manually record what happened. Running workflows in context reduces response time and context switching, and creates an auditable record of who initiated each action and what it targeted.

What to document

Entry points

The Run workflow action is available from the following surfaces. Document each entry point, what context it passes to the workflow, and how the result is surfaced:

Important: If the same surfaces are used outside a case (alerts page, alert flyout, Attack Discovery), the action routes through the generic Workflows API, not the Cases API, and no case activity entry is created. This is by design — document the distinction.

10-case limit: When more than 10 cases are selected in the cases list, Run workflow is disabled with an explanatory tooltip. Document the limit and the single-execution behavior (one execution covers all selected cases, not one execution per case).

Observable values in workflow inputs: When a workflow is run from an observable surface, the workflow receives and but not observable values. To read current values inside the workflow, use a step after the trigger or run. Document this so authors know to add that step rather than expecting values in the inputs.

Permissions and prerequisites

Two separate privilege grants are required. A user who has only one is rejected:

1. Workflows Management → workflow-execute sub-feature privilege () — requires an Enterprise license (or trial for self-managed). Granting Cases does not imply this.
2. **Cases ** for every case owner in the selection — missing rights on any one case blocks the entire run (no partial execution).

Additionally:

• Workflows must be available and enabled.
• The Run workflow action is hidden when any requirement is not met (rather than shown disabled).
• The feature is controlled by the feature flag. It is disabled by default.

Document subscription requirements separately:

• Running workflows from cases requires Enterprise (or trial).
• Observables (and therefore observable-origin runs) require Platinum or higher.

Activity log

Every manual run appends an entry to the case Activity log. Document what each entry contains and how it behaves:

• Who initiated the run, when, and what it ran against (case, observable(s), or alert/event attachment(s)).
• Workflow name — links to the execution details for users who also hold the workflow execution-read privilege; renders as plain text for everyone else.
• The activity limit is checked before the workflow is invoked. A case at its activity limit returns a 400 and nothing is scheduled.
• Recording is soft-failing: if the activity entry write fails after a successful run, the UI shows a warning rather than reporting the run as failed. The run did happen; only the bookkeeping failed.

Workflow tag filtering (Cases Settings)

Admins can configure Available workflow tags in Cases → Settings. Document this admin-only capability:

• When one or more tags are saved, every Run workflow picker in Cases shows only workflows that carry at least one of those tags.
• When the field is empty (the default), all enabled workflows are visible.
• Tag suggestions in the combo box come from workflows that already exist; free-form entries are also accepted.
• The setting section is hidden unless is , the Workflows UI feature is enabled, and the user has workflow read access.

trigger (Tech Preview)

A new event-driven trigger fires after new observables are persisted to a case. Document alongside the existing Cases workflow triggers.

Fires from:

• Adding observables manually (UI or )
• Auto-extraction when an alert or event attachment is added to a case with extraction enabled (this also fires for the same request)
• The step (and the Agent Builder observables tool that routes through it)

Does not fire when: every submitted observable is already on the case (duplicate adds return 400 with no trigger).

Trigger payload:

event:
  caseId: 'a1b2c3'
  owner: 'securitySolution'
  observableIds:
    - '9f0e8d7c-...'
    - '4a5b6c7d-...'
  observableTypeKeys:
    - 'observable-type-ipv4'
    - 'observable-type-ipv4'

• observableIds and observableTypeKeys are index-aligned arrays (one entry per new observable; the same type key repeats when multiple observables of the same type were added in one request).
• Observable values are deliberately absent. To read current values, use a cases.getCase step inside the workflow.
• Only newly-persisted observables appear — duplicates are excluded.

Loop prevention (required guidance):

The cases.addObservables step re-emits this trigger, which can cause a loop if a workflow triggered by cases.observablesAdded also adds observables. Document the required guard:

triggers:
  - type: cases.observablesAdded
    on:
      workflowEvents: ignore   # prevents the trigger from firing on executions started by a workflow

Without workflowEvents: ignore, a workflow that adds observables will re-trigger itself. The chain is bounded by workflowsExecutionEngine.eventDriven.maxChainDepth as a last resort, but the guard is the correct prevention mechanism.

API surface change

GET /api/cases/{caseId}/user_actions/_find can now return a new workflow user-action type and payload. The types query parameter also accepts workflow. Add a note (or release note callout) for API users:

API clients that use exhaustive enum handling, closed generated unions, or strict response deserialization must accept the new workflow variant or safely ignore unknown user-action types.

Where to add content

Check the existing documentation for the analogous Run workflow from alert action — the Cases entry points should follow the same pattern and link back to the Workflows documentation:

• Existing alert workflow action: https://www.elastic.co/docs/solutions/security/detect-and-alert/manage-detection-alerts#run-workflow-from-alert

Suggested pages to update or create:

• Cases user guide — add a "Run a workflow from a case" section covering all entry points, the 10-case limit, permissions, and activity log behavior.
• Cases Settings reference — add Available workflow tags.
• Workflow triggers reference — add cases.observablesAdded alongside existing Cases triggers; include the loop-prevention guidance.
• API changelog or release notes — note the new workflow user-action type.

Resources

• Product epic and complete scope: https://github.com/elastic/security-team/issues/17213
• Cases-owned workflow execution API: [Cases][Workflows] Add a Cases-owned workflow execution API wrapper kibana#287991
• Record workflow executions in case activity: [Cases][Workflows] Record workflow executions in case activity kibana#287992
• Run workflows from the case view and cases list: [Cases][Workflows] Run workflows from the case view and cases list kibana#287993
• Run workflows from case alerts and observables: [Cases][Workflows] Run workflows from case attachments via the Cases API kibana#287999
• Configure available workflow tags: [Cases][Workflows] Configure available workflow tags kibana#288001
• Telemetry for workflows run from cases: [Cases][Workflows] Add telemetry for workflows run from cases kibana#288138
• cases.observablesAdded trigger: [Cases] Add cases.observablesAdded workflow trigger kibana#288224
• Existing documentation for the analogous alert workflow action: https://www.elastic.co/docs/solutions/security/detect-and-alert/manage-detection-alerts#run-workflow-from-alert

Which deployment methods does this change impact?

Elastic On-Prem and Cloud (all)

Feature differences

No user-facing behavior differences between deployment methods. Availability depends on Workflows support, Enterprise subscription (or trial), 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