docs/v3/concepts/automations.mdx
Automations enable you to configure actions that execute automatically based on trigger conditions.
Potential triggers include the occurrence of events from changes in a flow run's state—or the absence of such events. You can define your own custom trigger to fire based on a custom event defined in Python code.
With Prefect Cloud you can even create webhooks that can receive data for use in actions.
Actions you can take upon a trigger include:
Triggers specify the conditions under which your action should be performed. The Prefect UI includes templates for many common conditions, such as:
OR criteria)Importantly, you can configure the triggers not only in reaction to events, but also proactively: in the absence of an expected event.
For example, in the case of flow run state change triggers, you might expect production flows to finish in no longer than thirty minutes. But transient infrastructure or network issues could cause your flow to get “stuck” in a running state. A trigger could kick off an action if the flow stays in a running state for more than 30 minutes.
This action could be taken on the flow itself, such as cancelling or restarting it. Or the action could take the form of a notification for someone to take manual remediation steps. Or you could set both actions to take place when the trigger occurs.
Actions specify what your automation does when its trigger criteria are met. Current action types include:
| Action | Type |
|---|---|
| Cancel a flow run | cancel-flow-run |
| Change the state of a flow run | change-flow-run-state |
| Suspend a flow run | suspend-flow-run |
| Resume a flow run | resume-flow-run |
| Run a deployment | run-deployment |
| Pause a deployment schedule | pause-deployment |
| Resume a deployment schedule | resume-deployment |
| Pause a work pool | pause-work-pool |
| Resume a work pool | resume-work-pool |
| Pause a work queue | pause-work-queue |
| Resume a work queue | resume-work-queue |
| Pause an automation | pause-automation |
| Resume an automation | resume-automation |
| Send a notification | send-notification |
| Call a webhook | call-webhook |
Some actions require you to either select the target of the action, or specify that the target of the action should be inferred. Selected targets are simple and useful for when you know exactly what object your action should act on. For example, the case of a cleanup flow you want to run or a specific notification you want to send.
Inferred targets are deduced from the trigger itself.
For example, if a trigger fires on a flow run that is stuck in a running state, and the action is to cancel an inferred flow run—the flow run that caused the trigger to fire.
Similarly, if a trigger fires on a work queue event and the corresponding action is to pause an inferred work queue, the inferred work queue is the one that emitted the event.
Prefect infers the relevant event whenever possible, but sometimes one does not exist.
Specify a name and, optionally, a description for the automation.
When an automation fires, it emits events that you can use to trace what happened:
prefect.automation.triggered or prefect.automation.resolved - emitted when the trigger condition is metprefect.automation.action.triggered - emitted when an action startsprefect.automation.action.executed or prefect.automation.action.failed - emitted when an action completesThe action events include related resources that link back to their source events:
| Related resource role | Description |
|---|---|
triggering-event | The original event that caused the automation to fire |
automation-triggered-event | The automation.triggered or automation.resolved event that prompted the action |
These links help you trace from an action failure back to the specific trigger and original event that caused it.
Automations support sending notifications through any predefined block that is capable of and configured to send a message, including:
For custom notification payloads, see the custom notifications guide.
You can access templated variables with automation actions through Jinja syntax. Templated variables enable you to dynamically include details from an automation trigger, such as a flow or pool name.
Jinja templated variable syntax wraps the variable name in double curly brackets, like this: {{ variable }}.
You can access properties of the underlying flow run objects including:
In addition to its native properties, each object includes an id along with created and updated timestamps.
The flow_run|ui_url token returns the URL to view the flow run in the UI.
Here's an example relevant to a flow run state-based notification:
Flow run {{ flow_run.name }} entered state {{ flow_run.state.name }}.
Timestamp: {{ flow_run.state.timestamp }}
Flow ID: {{ flow_run.flow_id }}
Flow Run ID: {{ flow_run.id }}
State message: {{ flow_run.state.message }}
The resulting Slack webhook notification looks something like this:
You could include flow and deployment properties:
Flow run {{ flow_run.name }} for flow {{ flow.name }}
entered state {{ flow_run.state.name }}
with message {{ flow_run.state.message }}
Flow tags: {{ flow_run.tags }}
Deployment name: {{ deployment.name }}
Deployment version: {{ deployment.version }}
Deployment parameters: {{ deployment.parameters }}
An automation that reports on work pool status might include notifications using work_pool properties:
Work pool status alert!
Name: {{ work_pool.name }}
Last polled: {{ work_pool.last_polled }}
In addition to those shortcuts for flows, deployments, and work pools, you have access to the automation and the event that triggered the automation. See the Automations API for additional details.
Automation: {{ automation.name }}
Description: {{ automation.description }}
Event: {{ event.id }}
Resource:
{% for label, value in event.resource %}
{{ label }}: {{ value }}
{% endfor %}
Related Resources:
{% for related in event.related %}
Role: {{ related.role }}
{% for label, value in related %}
{{ label }}: {{ value }}
{% endfor %}
{% endfor %}
Note that this example also illustrates the ability to use Jinja features such as iterator and for loop control structures when templating notifications.
For more on the common use case of passing an upstream flow run's parameters to the flow run invoked by the automation, see the Passing parameters to a flow run guide.