Trigger a flow in response to a state change in one or more other flows.
You can trigger a flow as soon as another flow ends. This allows you to add implicit dependencies between multiple flows, which can often be managed by different teams.
A flow trigger must have preconditions which filter on other flow executions.
It can also have standard trigger conditions. Neither condition type can use Pebble templating expressions; they must be declaratively defined.
Upstream execution outputs will be available in a trigger.outputs variable.
type: "io.kestra.plugin.core.trigger.Flow"Examples
- Trigger the
transformflow after theextractflow finishes successfully. Theextractflow generates adateoutput that is passed to thetransformflow as an input.
id: extract
namespace: company.team
tasks:
- id: final_date
type: io.kestra.plugin.core.debug.Return
format: "{{ execution.startDate | dateAdd(-2, 'DAYS') | date('yyyy-MM-dd') }}"
outputs:
- id: date
type: STRING
value: "{{ outputs.final_date.value }}"
The transform flow is triggered after the extract flow finishes successfully.
id: transform
namespace: company.team
inputs:
- id: date
type: STRING
defaults: "2025-01-01"
variables:
result: |
Ingestion done in {{ trigger.executionId }}.
Now transforming data up to {{ inputs.date }}
tasks:
- id: run_transform
type: io.kestra.plugin.core.debug.Return
format: "{{ render(vars.result) }}"
- id: log
type: io.kestra.plugin.core.log.Log
message: "{{ render(vars.result) }}"
triggers:
- id: run_after_extract
type: io.kestra.plugin.core.trigger.Flow
inputs:
date: "{{ trigger.outputs.date }}"
preconditions:
id: flows
flows:
- namespace: company.team
flowId: extract
states: [SUCCESS]- Trigger the
silver_layerflow once thebronze_layerflow finishes successfully by 9 AM.
id: bronze_layer
namespace: company.team
tasks:
- id: raw_data
type: io.kestra.plugin.core.log.Log
message: Ingesting raw data
id: silver_layer
namespace: company.team
tasks:
- id: transform_data
type: io.kestra.plugin.core.log.Log
message: deduplication, cleaning, and minor aggregations
triggers:
- id: flow_trigger
type: io.kestra.plugin.core.trigger.Flow
preconditions:
id: bronze_layer
timeWindow:
type: DAILY_TIME_DEADLINE
deadline: "09:00:00"
flows:
- namespace: company.team
flowId: bronze_layer
states: [SUCCESS]- Create a
System Flowto send a Slack alert on any failure or warning state within thecompanynamespace. This example uses the Slack webhook secret to notify the#generalchannel about the failed flow.
id: alert
namespace: system
tasks:
- id: send_alert
type: io.kestra.plugin.notifications.slack.SlackExecution
url: "{{secret('SLACK_WEBHOOK')}}" # format: https://hooks.slack.com/services/xzy/xyz/xyz
channel: "#general"
executionId: "{{trigger.executionId}}"
triggers:
- id: alert_on_failure
type: io.kestra.plugin.core.trigger.Flow
states:
- FAILED
- WARNING
preconditions:
id: company_namespace
where:
- id: company
filters:
- field: NAMESPACE
type: STARTS_WITH
value: company- Create a
System Flowto send a Sentry issue on any failure or warning state within thecompany.payrollnamespace. This example uses the Sentry Execution task and a Flow trigger withconditions.
id: sentry_execution_example
namespace: company.team
tasks:
- id: send_alert
type: io.kestra.plugin.notifications.sentry.SentryExecution
executionId: "{{ trigger.executionId }}"
transaction: "/execution/id/{{ trigger.executionId }}"
dsn: "{{ secret('SENTRY_DSN') }}"
level: ERROR
triggers:
- id: failed_prod_workflows
type: io.kestra.plugin.core.trigger.Flow
conditions:
- type: io.kestra.plugin.core.condition.ExecutionStatus
in:
- FAILED
- WARNING
- type: io.kestra.plugin.core.condition.ExecutionNamespace
namespace: company.payroll
prefix: falseProperties
conditions Non-dynamicDateTimeBetweenDayWeekDayWeekInMonthExecutionFlowExecutionLabelsExecutionNamespaceExecutionOutputsExecutionStatusExpressionFlowConditionFlowNamespaceConditionHasRetryAttemptMultipleConditionNotOrPublicHolidayTimeBetweenWeekend
List of conditions in order to limit the flow trigger.
inputs Non-dynamicobject
Pass upstream flow's outputs to inputs of the current flow.
The inputs property passes data objects or a file to the downstream flow as long as those outputs are defined on the flow-level in the upstream flow.
Make sure that the inputs and task outputs defined in this Flow trigger match the outputs of the upstream flow. Otherwise, the downstream flow execution will not to be created. If that happens, go to the Logs tab on the Flow page to investigate the error.
preconditions Non-dynamicFlow-Preconditions
Preconditions on upstream flow executions
Express preconditions to be met, on a time window, for the flow trigger to be evaluated.
states Non-dynamicarray
[
"SUCCESS",
"WARNING",
"FAILED",
"KILLED",
"CANCELLED",
"RETRIED",
"SKIPPED",
"PAUSED"
]CREATEDRUNNINGPAUSEDRESTARTEDKILLINGSUCCESSWARNINGFAILEDKILLEDCANCELLEDQUEUEDRETRYINGRETRIEDSKIPPEDBREAKPOINTList of execution states that will be evaluated by the trigger
By default, only executions in a terminal state or in the PAUSED state will be evaluated.
Any ExecutionStatus-type condition will be evaluated after the list of states. Note that a Flow trigger cannot react to the CREATED state because the Flow trigger reacts to state transitions. The CREATED state is the initial state of an execution and does not represent a state transition.
The trigger will be evaluated for each state change of matching executions. If a flow has two Pause tasks, the execution will transition from PAUSED to a RUNNING state twice — one for each Pause task. In this case, a Flow trigger listening to a PAUSED state will be evaluated twice.
stopAfter Non-dynamicarray
CREATEDRUNNINGPAUSEDRESTARTEDKILLINGSUCCESSWARNINGFAILEDKILLEDCANCELLEDQUEUEDRETRYINGRETRIEDSKIPPEDBREAKPOINTList of execution states after which a trigger should be stopped (a.k.a. disabled).
Outputs
executionId *Requiredstring
The execution ID that triggered the current flow
executionLabels *Requiredobject
The execution labels that triggered the current flow
flowId *Requiredstring
The flow ID whose execution triggered the current flow
flowRevision *Requiredinteger
The flow revision that triggered the current flow
namespace *Requiredstring
The namespace of the flow that triggered the current flow
state *Requiredstring
CREATEDRUNNINGPAUSEDRESTARTEDKILLINGSUCCESSWARNINGFAILEDKILLEDCANCELLEDQUEUEDRETRYINGRETRIEDSKIPPEDBREAKPOINTThe execution state
outputs object
The extracted outputs from the flow that triggered the current flow
Definitions
io.kestra.core.models.triggers.TimeWindow
deadline string
partial-timeSLA daily deadline
Use it only for DAILY_TIME_DEADLINE SLA.
endTime string
partial-timeSLA daily end time
Use it only for DAILY_TIME_WINDOW SLA.
startTime string
partial-timeSLA daily start time
Use it only for DAILY_TIME_WINDOW SLA.
type string
DURATION_WINDOWDAILY_TIME_DEADLINEDAILY_TIME_WINDOWDURATION_WINDOWSLIDING_WINDOWThe type of the SLA
The default SLA is a sliding window (DURATION_WINDOW) with a window of 24 hours.
window string
durationThe duration of the window
Use it only for DURATION_WINDOW or SLIDING_WINDOW SLA.
See ISO_8601 Durations for more information of available duration value.
The start of the window is always based on midnight except if you set windowAdvance parameter. Eg if you have a 10 minutes (PT10M) window,
the first window will be 00: 00 to 00: 10 and a new window will be started each 10 minutes
windowAdvance string
durationThe window advance duration
Use it only for DURATION_WINDOW SLA.
Allow to specify the start time of the window
Eg: you want a window of 6 hours (window=PT6H), by default the check will be done between: 00: 00 and 06: 00, 06: 00 and 12: 00, 12: 00 and 18: 00, and 18: 00 and 00: 00.
If you want to check the window between 03: 00 and 09: 00, 09: 00 and 15: 00, 15: 00 and 21: 00, and 21: 00 and 3: 00, you will have to shift the window of 3 hours by settings windowAdvance: PT3H
Condition for a specific flow of an execution.
flowId *Requiredstring
The flow id.
namespace *Requiredstring
The namespace of the flow.
type *Requiredobject
Condition for a flow namespace.
namespace *Requiredstring
The namespace of the flow or the prefix if prefix is true.
type *Requiredobject
prefix boolean
falseIf we must look at the flow namespace by prefix (checked using startsWith). The prefix is case sensitive.
Condition for a specific flow. Note that this condition is deprecated, use `io.kestra.plugin.core.condition.ExecutionFlow` instead.
flowId *Requiredstring
The flow id.
namespace *Requiredstring
The namespace of the flow.
type *Requiredobject
Condition to allow events between two specific times.
type *Requiredobject
after string
timeThe time to test must be after this one.
Must be a valid ISO 8601 time with offset.
before string
timeThe time to test must be before this one.
Must be a valid ISO 8601 time with offset.
date string
{{ trigger.date }}The time to test.
Can be any variable or any valid ISO 8601 time. By default, it will use the trigger date.
io.kestra.plugin.core.trigger.Flow-ExecutionFilter
Condition that checks labels of an execution.
labels *Requiredarrayobject
List of labels to match in the execution.
type *Requiredobject
Condition based on the outputs of an upstream execution.
expression *Requiredbooleanstring
type *Requiredobject
Condition to allow events on weekend.
type *Requiredobject
date string
{{ trigger.date }}The date to test.
Can be any variable or any valid ISO 8601 datetime. By default, it will use the trigger date.
io.kestra.plugin.core.trigger.Flow-UpstreamFlow
namespace *Requiredstring
The namespace of the flow
flowId string
The flow ID
labels object
A key/value map of labels
states array
CREATEDRUNNINGPAUSEDRESTARTEDKILLINGSUCCESSWARNINGFAILEDKILLEDCANCELLEDQUEUEDRETRYINGRETRIEDSKIPPEDBREAKPOINTThe execution states
io.kestra.plugin.core.trigger.Flow-Preconditions
id *Requiredstring
^[a-zA-Z0-9][a-zA-Z0-9_-]*1A unique id for the preconditions
resetOnSuccess boolean
trueWhether to reset the evaluation results of preconditions after a first successful evaluation within the given time window
By default, after a successful evaluation of the set of preconditions, the evaluation result is reset. This means the same set of conditions needs to be successfully evaluated again within the same time window to trigger a new execution.
In this setup, to create multiple executions, the same set of conditions must be evaluated to true multiple times within the defined window.
You can disable this by setting this property to false, so that within the same window, each time one of the conditions is satisfied again after a successful evaluation, it will trigger a new execution.
timeWindow TimeWindow
{
"type": "DURATION_WINDOW"
}Define the time window for evaluating preconditions.
You can set the type of timeWindow to one of the following values:
DURATION_WINDOW: this is the defaulttype. It uses a start time (windowAdvance) and end time (window) that advance to the next interval whenever the evaluation time reaches the end time, based on the defined durationwindow. For example, with a 1-day window (the default option:window: PT1D), the preconditions are evaluated during a 24-hour period starting at midnight (i.e., at "00: 00: 00+00: 00") each day. If you setwindowAdvance: PT6H, the window will start at 6 AM each day. If you setwindowAdvance: PT6Hand also override thewindowproperty toPT6H, the window will start at 6 AM and last for 6 hours. In this configuration, the preconditions will be evaluated during the following intervals: 06: 00 to 12: 00, 12: 00 to 18: 00, 18: 00 to 00: 00, and 00: 00 to 06: 00.SLIDING_WINDOW: this option evaluates preconditions over a fixed timewindowbut always goes backward from the current time. For example, a sliding window of 1 hour (window: PT1H) evaluates executions within the past hour (from one hour ago up to now). It uses a default window of 1 day.DAILY_TIME_DEADLINE: this option declares that preconditions should be met "before a specific time in a day." Using the string propertydeadline, you can configure a daily cutoff for evaluating preconditions. For example,deadline: "09: 00: 00"specifies that preconditions must be met from midnight until 9 AM UTC time each day; otherwise, the flow will not be triggered.DAILY_TIME_WINDOW: this option declares that preconditions should be met "within a specific time range in a day". For example, a window fromstartTime: "06: 00: 00"toendTime: "09: 00: 00"evaluates executions within that interval each day. This option is particularly useful for defining freshness conditions declaratively when building data pipelines that span multiple teams and namespaces. Normally, a failure in any task in your flow will block the entire pipeline, but with this decoupled flow trigger alternative, you can proceed as soon as the data is successfully refreshed within the specified time window.
Condition to have at least one condition validated.
conditions *RequiredDateTimeBetweenDayWeekDayWeekInMonthExecutionFlowExecutionLabelsExecutionNamespaceExecutionOutputsExecutionStatusExpressionFlowConditionFlowNamespaceConditionHasRetryAttemptMultipleConditionNotOrPublicHolidayTimeBetweenWeekend
1The list of conditions to validate.
If any condition is true, it will allow the event's execution.
type *Requiredobject
Condition for an execution namespace.
namespace *Requiredstring
String against which to match the execution namespace depending on the provided comparison.
type *Requiredobject
comparison string
EQUALSPREFIXSUFFIXComparison to use when checking if namespace matches. If not provided, it will use EQUALS by default.
prefix booleanstring
falseWhether to look at the flow namespace by prefix. Shortcut for comparison: PREFIX.
Only used when comparison is not set
Run a flow if the list of preconditions is met in a time window.
conditions *Requiredobject
id *Requiredstring
^[a-zA-Z0-9][a-zA-Z0-9_-]*1A unique id for the condition
type *Requiredobject
resetOnSuccess boolean
trueWhether to reset the evaluation results of SLA conditions after a first successful evaluation within the given time period.
By default, after a successful evaluation of the set of SLA conditions, the evaluation result is reset, so, the same set of conditions needs to be successfully evaluated again in the same time period to trigger a new execution.
This means that to create multiple executions, the same set of conditions needs to be evaluated to true multiple times.
You can disable this by setting this property to false so that, within the same period, each time one of the conditions is satisfied again after a successful evaluation, it will trigger a new execution.
timeWindow TimeWindow
{
"type": "DURATION_WINDOW"
}Define the time period (or window) for evaluating preconditions.
You can set the type of sla to one of the following values:
DURATION_WINDOW: this is the defaulttype. It uses a start time (windowAdvance) and end time (window) that are moving forward to the next interval whenever the evaluation time reaches the end time, based on the defined durationwindow. For example, with a 1-day window (the default option:window: PT1D), the SLA conditions are always evaluated during 24h starting at midnight (i.e. at time 00: 00: 00) each day. If you setwindowAdvance: PT6H, the window will start at 6 AM each day. If you setwindowAdvance: PT6Hand you also override thewindowproperty toPT6H, the window will start at 6 AM and last for 6 hours — as a result, Kestra will check the SLA conditions during the following time periods: 06: 00 to 12: 00, 12: 00 to 18: 00, 18: 00 to 00: 00, and 00: 00 to 06: 00, and so on.SLIDING_WINDOW: this option also evaluates SLA conditions over a fixed timewindow, but it always goes backward from the current time. For example, a sliding window of 1 hour (window: PT1H) will evaluate executions for the past hour (so between now and one hour before now). It uses a default window of 1 day.DAILY_TIME_DEADLINE: this option declares that some SLA conditions should be met "before a specific time in a day". With the string propertydeadline, you can configure a daily cutoff for checking conditions. For example,deadline: "09: 00: 00"means that the defined SLA conditions should be met from midnight until 9 AM each day; otherwise, the flow will not be triggered.DAILY_TIME_WINDOW: this option declares that some SLA conditions should be met "within a given time range in a day". For example, a window fromstartTime: "06: 00: 00"toendTime: "09: 00: 00"evaluates executions within that interval each day. This option is particularly useful for declarative definition of freshness conditions when building data pipelines. For example, if you only need one successful execution within a given time range to guarantee that some data has been successfully refreshed in order for you to proceed with the next steps of your pipeline, this option can be more useful than a strict DAG-based approach. Usually, each failure in your flow would block the entire pipeline, whereas with this option, you can proceed with the next steps of the pipeline as soon as the data is successfully refreshed at least once within the given time range.
Condition to exclude other conditions.
conditions *RequiredDateTimeBetweenDayWeekDayWeekInMonthExecutionFlowExecutionLabelsExecutionNamespaceExecutionOutputsExecutionStatusExpressionFlowConditionFlowNamespaceConditionHasRetryAttemptMultipleConditionNotOrPublicHolidayTimeBetweenWeekend
1The list of conditions to exclude.
If any condition is true, it will prevent the event's execution.
type *Requiredobject
Condition to execute tasks on a specific day of the week relative to the current month (first, last, ...)
dayInMonth *Requiredstring
FIRSTLASTSECONDTHIRDFOURTHAre you looking for the first or the last day in the month?
dayOfWeek *Requiredstring
MONDAYTUESDAYWEDNESDAYTHURSDAYFRIDAYSATURDAYSUNDAYThe day of week.
type *Requiredobject
date string
{{ trigger.date }}The date to test.
Can be any variable or any valid ISO 8601 datetime. By default, it will use the trigger date.
Condition based on variable expression.
expression *Requiredstring
type *Requiredobject
Condition to allow events on a particular day of the week.
dayOfWeek *Requiredstring
MONDAYTUESDAYWEDNESDAYTHURSDAYFRIDAYSATURDAYSUNDAYThe day of week.
type *Requiredobject
date string
{{ trigger.date }}The date to test.
Can be any variable or any valid ISO 8601 datetime. By default, it will use the trigger date.
Condition based on execution status.
type *Requiredobject
in array
CREATEDRUNNINGPAUSEDRESTARTEDKILLINGSUCCESSWARNINGFAILEDKILLEDCANCELLEDQUEUEDRETRYINGRETRIEDSKIPPEDBREAKPOINTList of states that are authorized.
notIn array
CREATEDRUNNINGPAUSEDRESTARTEDKILLINGSUCCESSWARNINGFAILEDKILLEDCANCELLEDQUEUEDRETRYINGRETRIEDSKIPPEDBREAKPOINTList of states that aren't authorized.
Condition to allow events between two specific datetime values.
type *Requiredobject
after string
date-timeThe date to test must be after this one.
Must be a valid ISO 8601 datetime with the zone identifier (use 'Z' for the default zone identifier).
before string
date-timeThe date to test must be before this one.
Must be a valid ISO 8601 datetime with the zone identifier (use 'Z' for the default zone identifier).
date string
{{ trigger.date }}The date to test.
Can be any variable or any valid ISO 8601 datetime. By default, it will use the trigger date.
io.kestra.plugin.core.trigger.Flow-Filter
field *Requiredstring
FLOW_IDNAMESPACESTATEEXPRESSIONThe field which will be filtered
type *Requiredstring
EQUAL_TONOT_EQUAL_TOINNOT_INIS_TRUEIS_FALSEIS_NULLIS_NOT_NULLSTARTS_WITHENDS_WITHREGEXCONTAINSThe type of filter
Can be set to one of the following: EQUAL_TO, NOT_EQUAL_TO, IS_NULL, IS_NOT_NULL, IS_TRUE, IS_FALSE, STARTS_WITH, ENDS_WITH, REGEX, CONTAINS. Depending on the type, you will need to also set the value or values property.
value string
The single value to filter the field on
Must be set according to its type.
values array
The list of values to filter the field on
Must be set for the following types: IN, NOT_IN.
Condition that matches if any taskRun has retry attempts.
type *Requiredobject
in array
CREATEDRUNNINGPAUSEDRESTARTEDKILLINGSUCCESSWARNINGFAILEDKILLEDCANCELLEDQUEUEDRETRYINGRETRIEDSKIPPEDBREAKPOINTList of states that are authorized.
notIn array
CREATEDRUNNINGPAUSEDRESTARTEDKILLINGSUCCESSWARNINGFAILEDKILLEDCANCELLEDQUEUEDRETRYINGRETRIEDSKIPPEDBREAKPOINTList of states that aren't authorized.
Condition to allow events on public holidays.
type *Requiredobject
country string
ISO 3166-1 alpha-2 country code. If not set, it uses the country code from the default locale.
It uses the Jollyday library for public holiday calendar that supports more than 70 countries.
date string
{{ trigger.date }}The date to test.
Can be any variable or any valid ISO 8601 datetime. By default, it will use the trigger date.
subDivision string
ISO 3166-2 country subdivision (e.g., provinces and states) code.
It uses the Jollyday library for public holiday calendar that supports more than 70 countries.