Core Plugins and tasks Flow
CertifiedTrigger a Flow based on other Flows’ executions.
Core Plugins and tasks Flow
Trigger a Flow based on other Flows’ executions.
Fires when upstream Flow executions meet dependsOn (required) and optional trigger when condition. Lets you chain Flows owned by different teams.
Upstream execution outputs are exposed under trigger.outputs; you can also pass inputs to the downstream Flow.
type: io.kestra.plugin.core.trigger.FlowExamples
- 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 }}"
dependsOn:
- namespace: company.team
flowId: extract
states: [SUCCESS]- Trigger the
silver_layerflow once thebronze_layerflow finishes successfully by 9 AM Paris time.
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
window:
deadline: "09:00:00"
timezone: Europe/Paris
dependsOn:
- 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
when: "{{flow.namespace | startsWith('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 withdependsOn.
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
dependsOn:
- states
- FAILED
- WARNING
namespace: company.payroll- Chain two different flows (
flow_aandflow_b) and triggerflow_bonly afterflow_acompletes successfully with matching labels. Note that this example shows two separate flows.
id: flow_a
namespace: company.team
labels:
type: orchestration
tasks:
- id: hello
type: io.kestra.plugin.core.log.Log
message: Hello World!
---
id: flow_b
namespace: company.team
tasks:
- id: hello
type: io.kestra.plugin.core.log.Log
message: Hello World!
triggers:
- id: on_completion
type: io.kestra.plugin.core.trigger.Flow
dependsOn:
- namespace: company.team
flowId: flow_a
states: [SUCCESS]
labels:
type: orchestration
Properties
allowConcurrent Non-dynamicboolean
falseSpecifies whether a trigger is allowed to start a new execution even if a previous run is still in progress.
dependsOn Non-dynamicarray
Dependencies on upstream flow executions
Express dependencies on upstream flow executions, which must be met for the flow trigger to be evaluated.
io.kestra.plugin.core.trigger.Flow-Dependency
The flow ID
A key/value map of labels
The namespace of the flow
CREATEDSUBMITTEDRUNNINGPAUSEDRESTARTEDKILLINGSUCCESSWARNINGFAILEDKILLEDCANCELLEDQUEUEDRETRYINGRETRIEDSKIPPEDBREAKPOINTRESUBMITTEDThe execution states
trueA condition that determines whether the trigger should run for that dependency.
A Pebble expression evaluated at trigger time. The trigger fires only when the expression evaluates to a truthy value (true, a non-empty string, a non-zero number). Use this to gate trigger execution on dynamic runtime values such as execution labels, flow variables, or environment conditions.
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. ::alert{type="warning"} 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. ::
minSatisfied Non-dynamicinteger
> Minimum number of satisfied dependsOn conditions for AT_LEAST mode
When mode is set to AT_LEAST, this specifies the minimum number of conditions that must be satisfied within the window.
mode Non-dynamicstring
ALLALLANYAT_LEASTMode for evaluating dependsOn conditions
Specifies how the dependsOn conditions should be evaluated: ALL, ANY, or AT_LEAST.
When using AT_LEAST, you must also set minSatisfied to the minimum number of conditions that must be satisfied within the window.
states Non-dynamicarray
[
"SUCCESS",
"WARNING",
"FAILED",
"KILLED",
"CANCELLED",
"RETRIED",
"SKIPPED",
"RESUBMITTED",
"PAUSED"
]CREATEDSUBMITTEDRUNNINGPAUSEDRESTARTEDKILLINGSUCCESSWARNINGFAILEDKILLEDCANCELLEDQUEUEDRETRYINGRETRIEDSKIPPEDBREAKPOINTRESUBMITTEDList 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.
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.
::alert{type="info"}
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
CREATEDSUBMITTEDRUNNINGPAUSEDRESTARTEDKILLINGSUCCESSWARNINGFAILEDKILLEDCANCELLEDQUEUEDRETRYINGRETRIEDSKIPPEDBREAKPOINTRESUBMITTEDList of execution states after which a trigger should be stopped (a.k.a. disabled).
when string
trueA condition that determines whether the trigger should run.
A Pebble expression evaluated at trigger time. The trigger fires only when the expression evaluates to a truthy value (true, a non-empty string, a non-zero number). Use this to gate trigger execution on dynamic runtime values such as execution labels, flow variables, or environment conditions.
window Non-dynamic
Window configuration for the dependsOn trigger
Configure the time window within which all dependsOn conditions must be met.
Window configuration
Defines the time window within which all dependsOn conditions must be met for the trigger to fire.
The window type is inferred from the fields that are set:
deadlineset: daily time deadline window (conditions must be met before the given time each day).fromandtoboth set: daily time window (conditions must be met within the given time range each day).lookbackset: sliding window (conditions must be met within the past duration).- otherwise: duration window (default, conditions must be met within a fixed duration, configurable via
everyandoffset).deadline,from,to,everyandoffsetare resolved daily/midnight boundaries anchored ontimezone(defaults to the server timezone);lookbackis unaffected bytimezone.
partial-timeDaily deadline
Use this to define a DAILY_TIME_DEADLINE window: the dependsOn conditions must be met before this time each day. Mutually exclusive with from, to, lookback, every, and offset.
durationDuration window size
Use this to define the size of a DURATION_WINDOW: the dependsOn conditions must be met within a fixed-duration window that advances at the given interval. Defaults to 1 day. Mutually exclusive with deadline, from, to, and lookback.
partial-timeDaily window start time
Use this together with to to define a DAILY_TIME_WINDOW: the dependsOn conditions must be met within the time range [from, to] each day. Mutually exclusive with deadline, lookback, every, and offset.
durationSliding window lookback duration
Use this to define a SLIDING_WINDOW: the dependsOn conditions must be met within the past duration relative to the current time. Mutually exclusive with deadline, from, to, every, and offset.
durationDuration window offset
Use this to shift the start of the DURATION_WINDOW relative to midnight. For example, PT6H shifts the window start by 6 hours when combined with a 1-day every. Mutually exclusive with deadline, from, to, and lookback.
The timezone used to resolve the daily deadline, start and end times
Defaults to the server timezone. Set a time-zone ID such as Europe/Paris so that daily windows follow the intended zone, including daylight-saving transitions. Has no effect on lookback.
partial-timeDaily window end time
Use this together with from to define a DAILY_TIME_WINDOW: the dependsOn conditions must be met within the time range [from, to] each day. Mutually exclusive with deadline, lookback, every, and offset.
Outputs
endDate *Requiredstring
date-timeThe execution end date
In case multiple executions triggered the current flow, this will be the last one.
executionId *Requiredstring
The execution ID that triggered the current flow
In case multiple executions triggered the current flow, this will be the last one.
executionLabels *Requiredobject
The execution labels that triggered the current flow
In case multiple executions triggered the current flow, this will be the last one.
flowId *Requiredstring
The flow ID whose execution triggered the current flow
In case multiple executions triggered the current flow, this will be the last one.
flowRevision *Requiredinteger
The flow revision that triggered the current flow
In case multiple executions triggered the current flow, this will be the last one.
namespace *Requiredstring
The namespace of the flow that triggered the current flow
In case multiple executions triggered the current flow, this will be the last one.
startDate *Requiredstring
date-timeThe execution start date
In case multiple executions triggered the current flow, this will be the last one.
state *Requiredstring
CREATEDSUBMITTEDRUNNINGPAUSEDRESTARTEDKILLINGSUCCESSWARNINGFAILEDKILLEDCANCELLEDQUEUEDRETRYINGRETRIEDSKIPPEDBREAKPOINTRESUBMITTEDThe execution state
In case multiple executions triggered the current flow, this will be the last one.
firstFailedTaskId string
The first failed task ID from the execution that triggered the current flow
In case multiple executions triggered the current flow, this will be the last one.
lastTaskId string
The last task ID from the execution that triggered the current flow
In case multiple executions triggered the current flow, this will be the last one.
outputs object
The extracted outputs from the flows that triggered the current flow
As there can be multiple executions that trigger this flow, each output will be prefixed by its namespace and flow ID. For example, 'namespace.flowId.key' will be the key for the output 'key' from the flow with ID 'flowId' in namespace 'namespace'.
