Understand workflow triggers

Trigger types

Automation orchestrator supports four trigger types. Each trigger type serves a different automation pattern.

Manual

Starts the workflow when a user clicks Run in the UI or sends a request to the workflow run API. The manual trigger requires no additional configuration. Use manual triggers for on-demand tasks such as ad hoc troubleshooting or operator-initiated changes.

Schedule

Starts the workflow at a recurring time or interval. You can define schedules using a visual schedule builder with preset frequencies (minutely, hourly, daily, weekly, monthly, yearly), or custom cron expressions. The visual schedule builder includes time zone selection. Both schedule expression types support a missed schedule behavior policy that controls how the system handles delayed or overlapping runs. Use schedule triggers for recurring tasks such as compliance scans, report generation, or periodic maintenance.

Webhook

Starts the workflow when an external system sends an authenticated HTTP request to a generated endpoint URL. The external system authenticates by obtaining a Bearer token from a service account authorized for the webhook. Use webhook triggers to integrate with CI/CD pipelines, monitoring systems, or any external application that can send HTTP callbacks.

Event-Driven Ansible

Starts the workflow using an action defined in an Event-Driven Ansible controller instance connected to Ansible Automation Platform. The Event-Driven Ansible trigger uses the webhook mechanism but is presented separately to highlight the Ansible Automation Platform integration. Use Event-Driven Ansible triggers for event-driven automation such as responding to infrastructure alerts, service failures, or configuration drift.

API

You can trigger workflows programmatically by sending a POST request to /api/v1/executions. This differs from webhook and schedule triggers in how it resolves the workflow version.

Webhook and schedule triggers always run the published version of a workflow. API-triggered executions accept a use_published parameter that controls version resolution:

• use_published: true runs the published version (recommended for production integrations)
• use_published: false runs the current draft version (used by the workflow builder Run button)

External systems must set use_published: true. This ensures the execution respects workflow publication status. If you set use_published: false or omit it, the API runs the current draft version. Unpublishing the workflow does not block execution. To disable access in that case, you must remove the trigger, revoke service account access, or delete the workflow.

How triggers work on the canvas

The trigger step is always the first step in a workflow. It appears at the top of the canvas and connects to the first action step in the workflow.

The trigger type determines how the workflow starts. After the trigger fires, the workflow executes the remaining steps in sequence. Downstream steps can reference the input data provided by the trigger, such as a webhook payload or event data, as input variables during execution.

A workflow can have multiple trigger steps.

The trigger step displays its type and configuration summary directly on the canvas. During a workflow run, the trigger step shows a status indicator (completed, running, or failed) like any other step.

When to use Event-Driven Ansible triggers

Event-Driven Ansible is the recommended approach for event detection that feeds data into workflows. Rather than using a task agent step to monitor for events, configure Event-Driven Ansible to detect events such as log patterns, monitoring alerts, or infrastructure changes. Event-Driven Ansible then forwards the event data to automation orchestrator, where downstream steps such as task agent steps can analyze the data and determine the appropriate response.

For example, Event-Driven Ansible can detect a CPU spike in your monitoring logs and send that data to a workflow. A task agent step in the workflow analyzes the logs and identifies the appropriate Ansible Automation Platform job template for remediation. An approval step pauses execution for human review before the job template runs.

How triggers pass data to a workflow

When a trigger fires, it can pass input data to the workflow. Downstream steps can reference these values as input variables during execution.

• Manual triggers pass the status field.
• Schedule triggers pass the scheduled time that initiated the run.
• Webhook triggers pass the HTTP request body directly as input data. You can structure the request payload so that downstream steps can reference specific fields.
• Event-Driven Ansible triggers pass the event data that matched the trigger configuration.

How triggers affect workflow run history

Each workflow run records which trigger initiated it. You can view this information in the run history for a workflow. Run history displays real-time status updates for each step, including the trigger step, with input and output details.

For schedule triggers, the run history shows the scheduled time that initiated the run. For webhook triggers, the run history includes the source of the HTTP request. For Event-Driven Ansible triggers, the run history shows the event that matched the trigger configuration. Manual runs display the status.