Data and error handling

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 workflow demonstrates a common pattern: searching for data in one step and using the results in a later step.

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: kibana.createCaseDefaultSpace
    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}}."
      tags: ["user-investigation"]
      connector:
        id: "none"
        name: "none"
        type: ".none"
		

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 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.

By default, if any step in a workflow fails, the entire workflow execution stops immediately. You can override this behavior using the on-failure block, which supports retry logic, fallback steps, and continuation options.

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 — applies to all steps as a default (under settings):

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

Retries the failed step a configurable number of times, with an optional delay between attempts.

on-failure:
  retry:
    max-attempts: 3  # Required, minimum 1 (for example, "1", "2", "5")
    delay: "5s"      # Optional, duration format (for example, "5s", "1m", "2h")
		

The workflow fails if all retries are exhausted.

Executes alternative steps after the primary step fails and all retries (if configured) are exhausted.

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 step using steps.<failed_step_name>.error.

Continues workflow execution even if a step fails. The failure is recorded, but does not interrupt the workflow.

on-failure:
  continue: true
		

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

- 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
		

In this example:

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

• Flow-control steps (if, foreach) cannot have workflow-level on-failure configurations.
• Fallback steps execute only after all retries have been exhausted.

To inject dynamic values into your workflow steps, use the templating engine. The templating engine uses the Liquid templating language and allows you to:

• Reference step outputs: Access data from previous steps using steps.<step_name>.output
• Use constants: Reference workflow-level constants with consts.<constant_name>
• Apply filters: Transform values with filters like upcase, downcase, and date
• Add conditional logic: Use if/else statements for dynamic content
• Loop through data: Iterate over arrays with for loops

For complete 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.