Skip to main content

What is a Workflow?

A Workflow in AWX is a structured composition of job resources that enables complex automation scenarios. Workflows execute jobs in a specific order based on success/failure paths, allowing you to chain together multiple job templates, project updates, inventory updates, and even other workflows into sophisticated automation pipelines.
Workflows transform simple automation tasks into powerful orchestration pipelines with conditional logic, parallel execution, and dependency management.

Core Concepts

Workflow Components

From the WorkflowJobTemplate model (awx/main/models/workflow.py:455-635): A workflow consists of:
  1. Workflow Job Template: The reusable definition
  2. Workflow Nodes: Individual steps in the workflow
  3. Node Relationships: Success, failure, and always paths between nodes
  4. Launch Configuration: Variables and prompts
  5. Approval Nodes: Manual approval steps

Workflow Job Templates

Key fields (workflow.py:455-467):

Workflow Nodes

Workflow nodes are the building blocks of workflows (awx/main/models/workflow.py:64-235):

Node Types

A node can reference any of these unified job templates:
  • Job Template: Run an Ansible playbook
  • Project Update: Sync a project from SCM
  • Inventory Update: Sync an inventory source
  • Workflow Job Template: Nested workflow
  • Workflow Approval: Manual approval step

Node Relationships

Success Nodes

Executed when parent node succeeds

Failure Nodes

Executed when parent node fails

Always Nodes

Executed regardless of parent status

Node Convergence

The all_parents_must_converge field controls execution logic:
  • False (default): Node runs if ANY parent’s condition is met
  • True: Node runs only if ALL parents’ conditions are met
This enables complex AND/OR logic in workflow graphs.

Node Identifiers

Nodes have an identifier field for tracking:
Identifiers enable:
  • Idempotent node creation/updates
  • Tracking job nodes back to template nodes
  • Client-side workflow management

Workflow Execution

When a workflow launches, it creates a Workflow Job (awx/main/models/workflow.py:637-789):

Execution Flow

From docs/workflow.md:110:
1

Create Workflow Job

Workflow job template creates a workflow job instance
2

Create Job Nodes

Each template node creates a corresponding job node
3

Start Root Nodes

Nodes with no parents begin execution
4

Follow Paths

As jobs complete, appropriate child nodes execute based on status
5

Complete

Workflow finishes when all decision trees complete

Node Job Creation

When a node’s turn comes, it creates a job:
Job parameters come from:
  1. Node-level prompts (highest priority)
  2. Workflow job prompts
  3. Template defaults (lowest priority)

Workflow Variables

Workflows have sophisticated variable handling:

Extra Variables

From docs/workflow.md:112:
Workflow-level extra variables override node and job template variables.

Artifact Passing

Jobs can pass data to downstream nodes using set_stats:
Artifacts flow through the workflow:
Artifacts from parent nodes are merged and passed as extra_vars to child jobs.
Artifacts marked with _ansible_no_log: true have their keys replaced with $hidden due to Ansible no_log flag$ to prevent exposure of sensitive data.

Workflow Approvals

Approval nodes pause workflow execution for manual approval (awx/main/models/workflow.py:829-1017):

Creating Approval Nodes

Approval Fields

Approval Actions

Approvals can be approved or denied:
Approved nodes continue to success path; denied nodes follow failure path.

Approval Permissions

From docs/workflow.md:82-93: Users can approve if they are:
  • Superuser
  • Organization Admin
  • Workflow Admin
  • Assigned the approval role on the workflow

Nested Workflows

Workflows can contain other workflows:
This enables:
  • Reusable workflow components
  • Complex multi-level orchestration
  • Recursion detection (AWX prevents infinite loops)
From docs/workflow.md:72-74:
In the event that spawning the workflow would result in recursion, the child workflow will be marked as failed with a message explaining that recursion was detected.

Job Slicing in Workflows

Workflows support job slicing:
When a job template with job_slice_count > 1 is launched, it creates a workflow job with slice nodes.

API Endpoints

List Workflow Job Templates

Create Workflow Job Template

Create Workflow Node

Create Approval Node

Launch Workflow

Approve Workflow Approval

Deny Workflow Approval

Workflow Status

Workflow job status is determined by node outcomes: From docs/workflow.md:133-134:
A workflow job is marked as failed if a job spawned by a workflow job fails, without a failure handler. A failure handler is a failure or always link in the workflow job template.
Status logic:
  • Successful: All execution paths completed successfully or handled failures
  • Failed: At least one node failed without a failure handler
  • Canceled: Workflow was canceled
  • Error: System error occurred

Permissions

Workflow job templates have these roles (workflow.py:481-504):
  • Admin Role: Full control over workflow
  • Execute Role: Can launch workflows
  • Approval Role: Can approve approval nodes
  • Read Role: Can view workflow details
The approval role is separate from execute role, allowing you to designate specific approvers who may not have permission to launch workflows.

Notifications

Workflows support standard notifications plus approval notifications:
Notification types:
  • Started: Workflow job starts
  • Success: Workflow job succeeds
  • Error: Workflow job fails
  • Approvals: Approval node needs attention

Best Practices

Always add failure handlers for critical paths. Use failure nodes to send notifications, roll back changes, or trigger remediation.
Add approval nodes before critical operations (production deployments, destructive changes) to ensure human oversight.
Use set_stats to pass data between jobs. This enables dynamic workflows that adapt based on upstream results.
Create smaller, reusable workflows rather than one massive workflow. Use nested workflows for modularity.
Set all_parents_must_converge: true only when you need AND logic. The default OR logic is more flexible.
Test all paths (success, failure, always) to ensure workflows behave correctly in all scenarios.

Workflow Visualization

From docs/workflow.md:154-174, AWX provides visual workflow execution tracking:
  • Root nodes start execution
  • Node colors indicate status (pending, running, successful, failed)
  • Paths show which branches executed
  • DNR (Do Not Run) marks nodes that won’t execute