Migrate workflows from 9.3 to 9.4

9.4 brings a handful of breaking changes to the workflow schema and HTTP step runtime behavior. Existing 9.3 workflows continue to run in most cases: the deprecated step aliases still resolve, timeout auto-migrates on save, and sub-minute schedules auto-migrate when edited. However, deployments with restrictive outbound action connector hosts might need a Kibana configuration update for HTTP steps.

This guide is the side-by-side for the migrations every 9.3 workflow author needs.

Case management moved out of the kibana.* namespace into its own cases.* namespace, and the new namespace uses snake_case parameters instead of the old camelCase.

9.4 also adds many new case steps that have no 9.3 equivalent. Check Cases action steps for the complete catalog.

# Old (9.3 — deprecated alias still works)
- name: open_case
  type: kibana.createCaseDefaultSpace
  with:
    title: "Alert on host-1"
    description: "..."
    severity: "high"
		

# New (9.4)
- name: open_case
  type: cases.createCase
  with:
    title: "Alert on host-1"
    description: "..."
    severity: "high"
    owner: "securitySolution"
		

# Old
- type: kibana.getCaseDefaultSpace
  with:
    caseId: "abc-123"
		

# New
- type: cases.getCase
  with:
    case_id: "abc-123"
		

Note the parameter rename: caseId (camelCase) becomes case_id (snake_case). This pattern applies to every parameter in the cases.* namespace.

The new cases.updateCase wraps the field changes in a required updates object:

# Old
- type: kibana.updateCaseDefaultSpace
  with:
    caseId: "abc-123"
    status: "closed"
    severity: "low"
		

# New — fields go inside `updates`
- type: cases.updateCase
  with:
    case_id: "abc-123"
    updates:
      status: "closed"
      severity: "low"
		

For single-field changes, use the dedicated setters:

- type: cases.setStatus
  with:
    case_id: "abc-123"
    status: "closed"
		

# Old
- type: kibana.addCaseCommentDefaultSpace
  with:
    caseId: "abc-123"
    comment: "Analyst note"
		

# New
- type: cases.addComment
  with:
    case_id: "abc-123"
    comment: "Analyst note"
		

In 9.3, the http step accepted timeout inside with. In 9.4, timeout is a standard common step field at the step top level, alongside if, foreach, on-failure, and others.

# Old
- type: http
  with:
    url: "https://example.com/webhook"
    timeout: "30s"
		

# New
- type: http
  timeout: "30s"
  with:
    url: "https://example.com/webhook"
		

Existing workflows auto-migrate on save. New workflows must use the new shape.

In 9.3, type: http steps without a connector-id used the workflow execution engine HTTP client and were controlled by workflowsExecutionEngine.http.allowedHosts.

In 9.4, those HTTP steps run through the Actions framework HTTP connector. As a result, outbound URLs are validated against xpack.actions.allowedHosts.

If xpack.actions.allowedHosts is not set, it defaults to ["*"], so all hosts are allowed. If your deployment sets a restrictive allowlist, add the hosts used by workflow HTTP steps:

xpack.actions.allowedHosts: ["api.example.com", "hooks.example.net"]
		

To allow all outbound hosts:

xpack.actions.allowedHosts: ["*"]
		

This setting applies to all action connectors, including connectors used by workflows. It does not apply to integrations, and it cannot currently be scoped per connector or per workflow.

For self-managed deployments, configure this in kibana.yml and restart Kibana. On Elastic Cloud Hosted, configure it in the deployment's Kibana user settings.

9.3 accepted any with.every value on a scheduled trigger, including sub-minute intervals such as 30s. 9.4 enforces a minimum of 1m / 60s.

# Old (9.3 — accepted)
triggers:
  - type: scheduled
    with:
      every: "30s"
		

# New (9.4 — rejected at save time)
triggers:
  - type: scheduled
    with:
      every: "1m"
		

1. minimum

Existing 9.3 workflows with sub-minute intervals auto-migrate to 1m when first edited.

Beyond the breaking changes, 9.4 adds many capabilities that don't require you to change existing workflows but are available for new ones:

• Workflows is enabled by default. The workflows:ui:enabled advanced setting now defaults to true on deployments with the appropriate subscription in Elastic Stack or project feature tier in Serverless.
• 27 cases.* steps. Full Cases API coverage. To learn more, refer to Cases action steps.
• Composition (technical preview). Call child workflows with typed inputs and outputs. To learn more, refer to Composition steps.
• Human-in-the-loop. Pause a workflow and resume after a human provides input. To learn more, refer to Human-in-the-loop.
• Event-driven triggers (technical preview). React to other workflow failures. To learn more, refer to Event-driven triggers.
• while and switch flow control. Even more control over workflow logic. To learn more, refer to Flow control steps.
• Expanded AI steps. ai.classify and ai.summarize join ai.prompt and ai.agent. To learn more, refer to AI steps.
• Data transformation steps. 11 data.* steps for inline data work: filter, map, aggregate, parse JSON, regex extract, and more. To learn more, refer to Data action steps.

• Cases action steps: Complete cases.* reference.
• Flow control steps: while, switch, and the other flow-control types added in 9.4.
• Scheduled triggers: Trigger configuration reference.