Pass data and handle errors

A key feature of workflows is the ability to pass data between steps and handle failures gracefully. This page explains the mechanisms for controlling data flow and building resilient, fault-tolerant automations.

Every step in a workflow produces an output. By default, this output is added to a global steps object in the workflow's context, making it available to all subsequent steps.

Use the following syntax to access the output of a specific step:

steps.<step_name>.output
		

You can also access error information from a step:

steps.<step_name>.error
		

This example demonstrates a common pattern: searching for data in one step and using the results in a later step. In this case, the workflow searches for a specific user's full name, then uses it to create a new security case.

name: Create case for a specific user
steps:
  - name: find_user_by_id
    type: elasticsearch.search
    with:
      index: "my-user-index"
      query:
        term:
          user.id: "u-123"

  - name: create_case_for_user
    type: cases.createCase
    with:
      title: "Investigate user u-123"
      description: "A case has been opened for user {{ steps.find_user_by_id.output.hits.hits[0]._source.user.fullName }}."
      owner: "securitySolution"
      tags: ["user-investigation"]
		

In this example:

1. The find_user_by_id step searches an index for a document.
2. The create_case_for_user step uses the output of the first step to enrich a new Elastic Security case.
3. The description field accesses steps.find_user_by_id.output.hits.hits[0]._source.user.fullName to dynamically include the user's full name in the case description.

By default, if any step fails the entire workflow execution stops immediately (the abort behavior). Override this with the on-failure block, which supports retry logic, fallback steps, and continuation. For failures that cross workflow boundaries, the workflows.failed trigger lets a separate handler workflow react after another workflow has failed.

You can configure on-failure at two levels:

Step-level — applies to a specific step:

steps:
  - name: api-call
    type: http
    on-failure:
      retry:
        max-attempts: 3
        delay: "5s"
		

Workflow-level (configured under settings) — applies to all steps as the default error handling behavior:

settings:
  on-failure:
    retry:
      max-attempts: 2
      delay: "1s"
steps:
  - name: api-call
    type: http
		

Precedence: per-step on-failure > workflow-level settings.on-failure > engine default (abort).

Retries the failed step a configurable number of times. The full shape accepts backoff strategy, maximum delay, jitter, and a KQL condition so you only retry on specific errors.

on-failure:
  retry:
    max-attempts: 5
    delay: "1s"               # Base delay between attempts. Duration format, for example "5s", "1m".
    strategy: exponential     # "fixed" (default) or "exponential".
    multiplier: 2
    max-delay: "30s"
    jitter: true
    condition: "steps.self.error.status : 429"
		

1. Total attempts, including the first. Required, minimum 1.
2. Only used with strategy: exponential.
3. Ceiling on the delay between retries.
4. Add randomness to avoid thundering-herd retry storms.
5. Optional KQL predicate over steps.self.error.

condition is a KQL expression evaluated against steps.self.error. Use it to retry only on specific failure modes: for example, retry on HTTP 429s and 5xxs but not on 4xx client errors.

The workflow fails when all retries are exhausted, unless paired with fallback or continue.

Runs alternative steps after the primary step fails and all retries are exhausted. In the following example, when the delete_critical_document step fails, the workflow runs two additional steps: one sends a Slack notification to devops-alerts using {{workflow.name}}, while the other logs the error details from the failed step using {{steps.delete_critical_document.error}}.

on-failure:
  fallback:
    - name: notify_on_failure
      type: slack
      connector-id: "devops-alerts"
      with:
        message: "Failed to delete document in workflow '{{workflow.name}}'"
    - name: log_failure
      type: console
      with:
        message: "Document deletion failed, error: {{steps.delete_critical_document.error}}"
		

Within fallback steps, access error information from the failed primary step using steps.<failed_step_name>.error.

Continues workflow execution even if a step fails. The failure is recorded at steps.<name>.error, but the workflow moves on to the next step. Use this for non-critical steps whose failure shouldn't take down the whole workflow.

on-failure:
  continue: true
		

Stops the workflow. This is the default when no on-failure is configured, so you rarely need to write it explicitly. Use abort when a downstream step depends on this step's output and continuing makes no sense.

You can combine multiple failure-handling options. They are processed in this order: retry → fallback → continue.

In the following example:

1. The step retries up to 2 times with a 1-second delay.
2. If all retries fail, the fallback steps run.
3. The workflow continues regardless of the outcome.

- name: create_ticket
  type: jira
  connector-id: "my-jira-project"
  with:
    projectKey: "PROJ"
    summary: "New issue from workflow"
  on-failure:
    retry:
      max-attempts: 2
      delay: "1s"
    fallback:
      - name: notify_jira_failure
        type: slack
        connector-id: "devops-alerts"
        with:
          message: "Warning: Failed to create ticket. Continuing workflow."
    continue: true
		

• Flow-control steps (if, foreach) cannot have workflow-level on-failure configurations.
• Fallback steps run only after all retries have been exhausted.
• When combined, failure-handling options are processed in this order: retry → fallback → continue.

For production-critical workflows, the final layer is a separate handler workflow that fires when another workflow fails. The workflows.failed trigger fires after a workflow execution reaches the failed terminal state, so you can build handlers that page on-call, open a case, or post to a dedicated index for workflow-failure observability. Refer to Event-driven triggers for the trigger reference and examples.

Workflows support dynamic values through template variables and template expressions.

• Template variables: The data you reference, such as step outputs (steps.<name>.output), constants (consts.<name>), inputs (inputs.<name>), and context variables (execution.id, event).
• Template expressions: The syntax used to insert variables. Use {{ }} for string output or ${{ }} to preserve data types like arrays and objects.

Template variables are the data sources you can reference inside template expressions. The following template variables are available:

Constants and inputs are both template variables that let you define reusable values in your workflow, but they serve different purposes:

• Constants — Use for values that are fixed for the workflow definition and don't change between runs, such as index names, API endpoints, and threshold values.
• Inputs — Use for values that might vary each time the workflow runs, such as user-provided parameters, environment toggles, or any value that changes per execution.

Use template expressions to insert template variables into your workflow. The templating engine supports two syntax options:

For syntax details and examples, refer to Templating engine.

By combining data flow, templating, and robust error handling, you can build complex, reliable automations that react to dynamic conditions and recover from unexpected failures.