Loading

Migrate workflows from 9.3 to 9.4

9.4 brings a handful of breaking changes to the workflow schema. Existing 9.3 workflows continue to run (the deprecated step aliases still resolve), but the editor blocks you from creating new workflows that use the old shapes, and several new capabilities are only available through the new shapes.

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

Change Old (9.3) New (9.4) What happens to existing workflows
Case management kibana.createCaseDefaultSpace, kibana.getCaseDefaultSpace, kibana.updateCaseDefaultSpace, kibana.addCaseCommentDefaultSpace cases.createCase, cases.getCase, cases.updateCase, cases.addComment (plus 23 additional cases.* steps) Deprecated aliases still work. New workflows must use cases.*.
HTTP step timeout Inside with At the step top level (common field) Existing workflows auto-migrate on save.
Scheduled trigger interval minimum Any duration Minimum 1m / 60s Sub-minute intervals auto-migrate to 1m on first edit.

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.

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.

Tip

If every: "30s" was a proxy for reacting quickly to something, consider switching to an alert trigger or an event-driven trigger. Scheduled polling is the slowest of the three trigger types.

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.