Workflows 9.4 content — part A (#6048)

## Summary

Adds documentation for the step categories, triggers, and authoring
patterns that ship in Workflows 9.4 GA. Follow-up to the IA restructure
([#5950](#5950)). All
schemas in this PR were cross-checked against the Kibana source of truth
([`elastic/kibana`](https://github.com/elastic/kibana)
`workflows_execution_engine`, `workflows_extensions`, `cases`, and
`agent_builder` plugins).

## What's new

**11 new reference and how-to pages:**

| Page | Covers |
|---|---|
| `steps/cases.md` | All 27 `cases.*` step types |
| `steps/data.md` | 11 `data.*` transformation steps |
| `steps/streams.md` | 3 `kibana.streams.*` steps (tech preview) |
| `steps/composition.md` | `workflow.execute`, `workflow.executeAsync`,
`workflow.output`, `workflow.fail` (tech preview) |
| `steps/while.md` | `while` step |
| `steps/switch.md` | `switch` step |
| `steps/loop-break.md` | `loop.break` step |
| `steps/loop-continue.md` | `loop.continue` step |
| `steps/wait-for-input.md` | `waitForInput` step |
| `triggers/event-driven-triggers.md` | `workflows.failed` trigger (tech
preview) |
| `authoring-techniques/human-in-the-loop.md` | HITL pattern using
`waitForInput` + resume API |
| `authoring-techniques/migrate-from-9.3.md` | 9.3 → 9.4 migration guide
|

**Expansions to existing pages:**

- `steps/ai-steps.md` — adds `ai.classify` and `ai.summarize` as
first-class step types; updates `ai.agent` with the `attachments` input
parameter and the correct output shape (`message` / `structured_output`
/ `conversation_id`).
- `steps/kibana.md` — documents `kibana.SetAlertsStatus` (all 5 body
params) and `kibana.SetAlertTags` with their PascalCase type IDs; lists
the deprecated Case aliases.
- `steps/flow-control-steps.md` — restructured as an overview of all 8
flow-control types with links to per-step child pages.
- `steps/action-steps.md` and `steps.md` — add Cases, Streams, Data, and
Composition to the step-category overview.
- `triggers.md` — adds event-driven trigger section.

## Open questions for reviewers

- **SME check requested on `workflows.failed`**: Does this trigger
support `on.condition` KQL filtering? The PM docs reference it, but the
common trigger schema doesn't currently expose it. If the filter exists
elsewhere in the registration pipeline, we'll add a filter section to
`triggers/event-driven-triggers.md`. /cc @shahargl
- **Resume API body shape on `waitForInput`**: The Kibana README example
shows direct output access (`steps.<name>.output.approvedBy`). PM docs
said the resume API wraps the body in `{ "input": ... }`. The HITL page
uses the README's direct-access form with a `%` comment flagging this.
Please confirm which is accurate before merge.
- **Cases step schemas beyond the five I read directly** (`createCase`,
`setCustomField`, `createCaseFromTemplate`, `updateCase`, `findCases`,
`addAlerts`, `addObservables`, plus the shared config): parameters for
the other 20 are adapted from PM docs. Engineering confirmation
appreciated, especially on `cases.findCases` query fields and
`cases.updateObservable`.

## How to review

1. **Nav diff**: See `explore-analyze/toc.yml` lines 464–494 for the new
IA shape.
2. **Big pages to read carefully**: `steps/cases.md` (27 sections),
`triggers/event-driven-triggers.md` (schema rewrite),
`authoring-techniques/migrate-from-9.3.md`.
3. **Small, mechanical changes**: `applies_to` bumps from `preview 9.3`
→ `ga 9.4` across ~20 existing files.

## Test plan

- [ ] Docs build passes with no broken internal links
- [ ] All 44 toc-referenced files resolve
- [ ] No Vale errors (warnings are false positives for Vale regex
matching "etc" inside "Fetch" / "getSignificantEvents")
- [ ] Nastasha: structural and style review
- [ ] Tinsae: confirm the new `cases.*`, `data.*`, and `composition`
content reflects the 9.4 GA product
- [ ] Engineering: resolve the two SME questions above

## Out of scope (for PR B and PR C)

- End-to-end pattern tutorials (alert→enrich→case, approval-gated
remediation, and so on) — PR B, as children under the Use cases outcome
sections.
- Reference lookup content: cheat sheet, step type A–Z index, full
context variables reference, Liquid filters reference, glossary,
troubleshooting FAQ — PR C.
- Anatomy of a workflow page, Settings page, enhanced error handling —
PR C.

## Related

- Parent IA restructure: #5950
- PM internal docset (private, Elastic-only):
elastic/workflows-internal-docs
- Kibana workflows plugins:
`src/platform/plugins/shared/{workflows_execution_engine,workflows_management,workflows_extensions}`;
`x-pack/platform/plugins/shared/cases/common/workflows/steps/`;
`x-pack/platform/plugins/shared/agent_builder/common/step_types/`

## Generative AI disclosure
1. Did you use a generative AI (GenAI) tool to assist in creating this
contribution?
- [x ] Yes — Claude 4.7 / Cursor  
- [ ] No

Author: benironside

explore-analyze/toc.yml

@@ -471,28 +471,40 @@ toc:
         children:
           - file: workflows/authoring-techniques/use-yaml-editor.md
           - file: workflows/authoring-techniques/pass-data-handle-errors.md
+          - file: workflows/authoring-techniques/human-in-the-loop.md
           - file: workflows/authoring-techniques/monitor-workflows.md
           - file: workflows/authoring-techniques/manage-workflows.md
+          - file: workflows/authoring-techniques/migrate-from-9.3.md
       - file: workflows/reference.md
         children:
           - file: workflows/triggers.md
             children:
               - file: workflows/triggers/manual-triggers.md
               - file: workflows/triggers/scheduled-triggers.md
               - file: workflows/triggers/alert-triggers.md
+              - file: workflows/triggers/event-driven-triggers.md
           - file: workflows/steps.md
             children:
               - file: workflows/steps/action-steps.md
                 children:
                   - file: workflows/steps/elasticsearch.md
                   - file: workflows/steps/kibana.md
+                  - file: workflows/steps/cases.md
+                  - file: workflows/steps/streams.md
                   - file: workflows/steps/external-systems-apps.md
               - file: workflows/steps/flow-control-steps.md
                 children:
                   - file: workflows/steps/if.md
                   - file: workflows/steps/foreach.md
+                  - file: workflows/steps/while.md
+                  - file: workflows/steps/switch.md
                   - file: workflows/steps/wait.md
+                  - file: workflows/steps/wait-for-input.md
+                  - file: workflows/steps/loop-break.md
+                  - file: workflows/steps/loop-continue.md
               - file: workflows/steps/ai-steps.md
+              - file: workflows/steps/data.md
+              - file: workflows/steps/composition.md
           - file: workflows/templating.md
       - file: workflows/templates.md
   - file: numeral-formatting.md

explore-analyze/workflows.md

@@ -1,7 +1,7 @@
 ---
 applies_to:
-  stack: preview 9.3
-  serverless: preview
+  stack: preview 9.3, ga 9.4+
+  serverless: ga
 description: Build automated workflows in Kibana to turn data insights into action.
 products:
   - id: kibana

explore-analyze/workflows/authoring-techniques.md

@@ -1,8 +1,8 @@
 ---
 navigation_title: Workflow authoring techniques
 applies_to:
-  stack: preview 9.3
-  serverless: preview
+  stack: preview 9.3, ga 9.4+
+  serverless: ga
 description: Techniques for authoring, running, monitoring, and organizing Elastic Workflows.
 products:
   - id: kibana
@@ -19,8 +19,10 @@ Techniques that apply across workflow types, regardless of which outcome you're
 
 - [Use the YAML editor](/explore-analyze/workflows/authoring-techniques/use-yaml-editor.md): Author and run workflows in the YAML editor in {{kib}}.
 - [Pass data and handle errors](/explore-analyze/workflows/authoring-techniques/pass-data-handle-errors.md): Move data between steps, use dynamic templating, and make workflows resilient with `on-failure`.
+- [Human-in-the-loop](/explore-analyze/workflows/authoring-techniques/human-in-the-loop.md): Pause a workflow for reviewer input and resume on their decision.
 - [Monitor workflow execution](/explore-analyze/workflows/authoring-techniques/monitor-workflows.md): Track runs, review execution history, and troubleshoot failures.
 - [Manage and organize workflows](/explore-analyze/workflows/authoring-techniques/manage-workflows.md): Find, edit, duplicate, enable, and disable workflows from the **Workflows** page.
+- [Migrate workflows from 9.3 to 9.4](/explore-analyze/workflows/authoring-techniques/migrate-from-9.3.md): Side-by-side replacements for the deprecated Case aliases, HTTP step `timeout` relocation, and scheduled-trigger minimum interval.
 
 % Ben Ironside Goldstein, 2026-04-16: Follow-up PRs per Vision doc Section 7 will split pass-data-handle-errors.md
 % into separate how-tos (Pass data between steps, Handle errors and retries, Use constants and inputs)

explore-analyze/workflows/authoring-techniques/human-in-the-loop.md

@@ -0,0 +1,158 @@
+---
+navigation_title: Human-in-the-loop
+applies_to:
+  stack: ga 9.4+
+  serverless: ga
+description: Pause a workflow to wait for human input, then resume with the reviewer's decision using the waitForInput step.
+products:
+  - id: kibana
+  - id: cloud-serverless
+  - id: cloud-hosted
+  - id: cloud-enterprise
+  - id: cloud-kubernetes
+  - id: elastic-stack
+---
+
+# Human-in-the-loop workflows [workflows-human-in-the-loop]
+
+Not every decision should be fully automated. *Human-in-the-loop* (HITL) is the pattern where a workflow pauses at a critical decision point, presents structured findings to a reviewer, waits for their input, and then resumes based on that input. It lets you combine the reach of automation with human judgment where judgment matters most.
+
+## When to reach for HITL
+
+- **Remediation with potential impact.** Isolating a host, blocking a user, or deleting data. Pause for analyst approval before the destructive action.
+- **Ambiguous classifications.** When an AI or rule is uncertain, ask a human before proceeding.
+- **Escalation gates.** Page an on-call, wait for acknowledgement and decision, then route accordingly.
+- **Approval for automation.** A new workflow in test mode can pause and ask for approval on each action for the first few runs, then switch to full automation once trusted.
+
+## The mechanism: `waitForInput`
+
+HITL is built on one step type: [`waitForInput`](/explore-analyze/workflows/steps/flow-control-steps.md#waitforinput). When the workflow reaches it, execution pauses. The reviewer sees the message (optionally with a form generated from a JSON Schema). When they respond, the workflow resumes with their input available as `steps.<step_name>.output`.
+
+## Design a good HITL form
+
+A HITL message is read by a human mid-incident. Design for speed:
+
+- **Lead with the decision.** The first line should say what the reviewer needs to decide.
+- **Include the evidence.** Relevant context (alert details, enrichment results, AI rationale) belongs in the message so the reviewer doesn't have to dig.
+- **Keep the schema small.** Three fields is a lot. One boolean plus an optional notes field is often enough.
+- **Use Markdown.** The message supports Markdown, so use headings, bold text, and bullets to make it scannable.
+
+## Write a HITL workflow
+
+The three ingredients: a preceding step that gathers context, a `waitForInput` step that presents it, and subsequent steps that branch on the reviewer's decision.
+
+```yaml
+name: isolate-host-with-approval
+enabled: true
+
+triggers:
+  - type: alert
+
+steps:
+  - name: open_case
+    type: cases.createCase
+    with:
+      title: "Potential compromise: {{ event.alerts[0].host.name }}"
+      severity: high
+      tags: ["auto-triage"]
+
+  - name: investigate
+    type: elasticsearch.search
+    with:
+      index: "logs-*"
+      query:
+        term:
+          "host.name": "{{ event.alerts[0].host.name }}"
+
+  - name: classify
+    type: ai.classify
+    connector-id: "my-openai"
+    with:
+      input: "${{ steps.investigate.output.hits.hits }}"
+      categories: ["confirmed_compromise", "likely_benign", "needs_review"]
+      includeRationale: true
+
+  - name: review
+    type: waitForInput
+    with:
+      message: |
+        ## Alert on `{{ event.alerts[0].host.name }}`
+
+        **AI classification:** {{ steps.classify.output.category }}
+
+        **Rationale:** {{ steps.classify.output.rationale }}
+
+        Isolate this host?
+      schema:
+        type: object
+        properties:
+          approved:
+            type: boolean
+            title: "Isolate the host"
+          notes:
+            type: string
+            title: "Analyst notes"
+        required: ["approved"]
+
+  - name: isolate
+    type: http
+    if: "steps.review.output.approved : true"
+    connector-id: "edr-connector"
+    with:
+      method: "POST"
+      url: "https://edr.example.com/isolate"
+      body:
+        host: "{{ event.alerts[0].host.name }}"
+        reason: "{{ steps.review.output.notes }}"
+
+  - name: record_decision
+    type: cases.addComment
+    with:
+      case_id: "{{ steps.open_case.output.case.id }}"
+      comment: |
+        **Decision:** {{ steps.review.output.approved ? "isolated" : "no action" }}
+        **Notes:** {{ steps.review.output.notes }}
+```
+
+Execution pauses at `review`. Until a reviewer responds, the execution state is `WAITING_FOR_INPUT`. When they respond, execution resumes at `isolate`, which is gated by an `if` guard on the approval decision.
+
+## Resume a paused workflow
+
+Resume a paused workflow using the following methods.
+
+### From the Kibana UI
+
+Open the execution view. The paused step renders a form generated from the `schema`. Fill it in, submit, and the workflow resumes.
+
+### From the API
+
+Send a `POST` request to the resume endpoint with the reviewer's input:
+
+```http
+POST /api/workflowExecutions/{executionId}/resume
+Content-Type: application/json
+
+{
+  "approved": true,
+  "notes": "Confirmed malicious. Proceeding with isolation."
+}
+```
+
+The input body is available to subsequent steps as `steps.<step_name>.output`. Reference individual fields like `{{ steps.review.output.approved }}` and `{{ steps.review.output.notes }}`.
+
+## What happens while the workflow is paused
+
+- The execution is in the `WAITING_FOR_INPUT` state. It appears in the execution history with a resume action.
+- There's no default timeout on `waitForInput`. The workflow waits indefinitely. To limit the wait, set a workflow-level `settings.timeout`.
+- If the workflow-level `settings.timeout` elapses before the reviewer responds, the execution is cancelled.
+
+## Related
+
+- [`waitForInput` step reference](/explore-analyze/workflows/steps/flow-control-steps.md#waitforinput): Step parameter details.
+- [AI steps](/explore-analyze/workflows/steps/ai-steps.md): Pair AI classification or summarization with HITL for uncertain cases.
+- [Cases action steps](/explore-analyze/workflows/steps/cases.md): Record decisions and outcomes on the case.
+
+% Ben Ironside Goldstein, 2026-04-16: The Kibana source README for wait_for_input_step shows the
+% output being accessed directly (e.g., steps.review.output.approved). PM internal docs claimed the
+% resume API wraps the body in { "input": ... }. Using the Kibana README's direct-access form here;
+% if engineering confirms the wrapped form is correct, update the API example above.

explore-analyze/workflows/authoring-techniques/manage-workflows.md

@@ -1,8 +1,8 @@
 ---
 navigation_title: Manage and organize workflows
 applies_to:
-  stack: preview 9.3
-  serverless: preview
+  stack: preview 9.3, ga 9.4+
+  serverless: ga
 description: Find, edit, duplicate, enable, disable, and run workflows from the Workflows page in Kibana.
 products:
   - id: kibana