Workflow concepts

Workflows connect automation steps into execution sequences. Build workflows in the graphical builder by connecting triggers, steps, and edges that define execution flow and data dependencies.

Technically, a workflow is a series of connected steps that represents the execution order and dependencies of automation steps.

On the back-end, a workflow consists of three structural elements:

• Triggers that start execution
• Steps that are nodes which perform work, such as applying judgment and routing information
• Edges that define the connections between nodes

You build workflows in the graphical workflow builder, which renders discrete units of automation work as visual units called steps in automation orchestrator. Each step connects to other steps through directed edges. The visual layout mirrors the logical execution flow, so you can trace the path from trigger to completion.

Steps represent discrete units of automation work. A single step can run an Ansible job template, call an HTTP API, run a script, request human approval, or call a large language model for analysis. Steps run only after all incoming dependencies are met, which ensures that each step has access to the data it needs. By composing nodes on the canvas, you create automation sequences that span multiple systems, tools, and decision points.

Edges define the execution order and carry data between steps. When a step completes, the workflow engine evaluates the outgoing edges to determine which step runs next. Some edges carry conditions, such as the "true" and "false" ports on a condition step, so you can branch execution based on runtime data.

A workflow may contain multiple trigger steps. At runtime, the execution is activated with one, respective trigger step. The trigger step defines how and when the workflow starts. Trigger types include:

• Manual triggers that you start on demand
• Webhook triggers that respond to HTTP requests from external systems
• Scheduled triggers that run on a time-based cadence
• Event-Driven Ansible triggers that respond to events from the Ansible event system

Logic steps govern how and when other nodes execute. They are the decision-making and coordination layer of a workflow.

Workflows support the following execution patterns:

Task

A node that performs concrete work, such as running an Ansible job template, calling an API, running a script, or requesting human approval.

Sequential

A chain of nodes connected by edges, where each node runs after the previous node completes.

Parallel

When a single node connects to multiple downstream nodes, those nodes run concurrently without requiring an explicit parallel block.

Conditional

Evaluates an expression and routes execution down a true or false path.

Switch

Evaluates an expression and routes execution down one of multiple exit paths.

Loop

Repeats a set of nodes, either iterating over a collection or until a condition is met.

Converge

Waits for all incoming parallel branches to finish before continuing.

Automation orchestrator preserves the state of every step as a workflow runs. If the system restarts or experiences a transient failure during a workflow run, the execution resumes from the last completed step.

If a step fails, what happens next depends on the step's 'on failure' setting:

• Continue on failure — The step is marked as failed and the workflow continues to the next step. The run finishes with a Completed error status.
• Stop workflow or branch on failure — Execution stops at the failed step.

You can configure the on-failure behavior on each step's Settings tab.

Each step in a workflow performs a distinct action when it runs, depending on its function. You can pass that output to any downstream step by using expressions that reference the producing step by name.

In addition to step outputs, you can reference data from other sources in your expressions.

Trigger

Data from whatever started the workflow, such as a webhook payload.

Loop

The current item and index during loop iteration.

Workflow context

Metadata about the current workflow and run, such as the workflow name, version, run ID, and timestamps.

You can also define which output fields a step exposes to downstream steps. By default, a step's full output is available.

Data flows forward through edges. A step can only reference steps that are upstream of it in the workflow.

Every workflow in automation orchestrator is defined as a structured document. While you typically build workflows visually using the workflow builder, the underlying definition is a document that you can export, version-control, and import across environments.

The definition captures the complete workflow configuration, including the name, description, triggers, nodes, and edges.

You can export a workflow definition and import it into another automation orchestrator environment. This enables version-controlled workflow management using Git or other source control systems. You can track changes over time, review modifications through pull requests, and roll back to earlier versions when needed.

Each workflow has a current version that reflects the latest saved state and a published version that represents the version available for execution. This separation means you can iterate on a workflow definition without affecting the published version until you are ready to deploy changes.