Workflows

What is a workflow?

A workflow is a directed sequence of playbook executions. Steps run in order; each step can branch on success or failure, letting you build pipelines like: provision servers → deploy app → run smoke tests → notify on failure.

Creating a workflow

Go to Workflows → New workflow. Give the workflow a name, then add steps using the visual builder.

Step configuration

• PlaybookWhich playbook this step runs
• InventoryTarget inventory for this step (can differ per step)
• Run optionsExtra vars, vault, tags — same as the manual run dialog
• On failure'stop' aborts the workflow, or 'continue' runs the next step anyway
• Propagate variablesPass variables registered in this step to the next one

Failure handling

Steps run in order. Each step has an on_failure setting with two values: stop aborts the workflow and marks it failed, while continue runs the next step regardless of the result. The sequence is linear — there is no arbitrary step-to-step routing.

[provision]  --(on_failure: stop)-->     [deploy]  --(on_failure: continue)-->  [smoke-tests]  -->  done
     |                                       |
  fails → workflow marked failed         fails → next step still runs

Variable propagation

Variables output by one step can be passed to the next. Use Ansible’s set_fact module to register a variable in a playbook, then reference it as an extra var in the next step using the {{ var_name }} syntax in the extra vars field.

# In step 1 playbook
- name: Register deployed version
  set_fact:
    deployed_version: "{{ git_sha }}"

# In step 2 extra vars (set in the workflow builder)
# version: "{{ deployed_version }}"  ← resolved from step 1 output

Running a workflow

Click Run on a workflow. Execution proceeds step by step. The workflow execution view shows all steps with their status in real time — you can expand any step to see the full playbook output.

Workflow execution status

Scheduling and triggering workflows

Workflows can be scheduled with cron expressions (same as individual playbooks) and can be triggered by webhooks. This makes them suitable as the execution target for CI/CD pipelines.