Tasks

Tasks are the steps within a flow.

They represent discrete actions, capable of processing inputs and variables and producing outputs for downstream consumption by end users and other tasks.

Flowable tasks

Kestra orchestrates flows using Flowable tasks. These tasks do not perform heavy computation. Instead, they control orchestration behavior, enabling advanced workflow patterns.

Example Flowable tasks include:

• io.kestra.plugin.core.flow.Parallel
• io.kestra.plugin.core.flow.Switch
• io.kestra.plugin.core.flow.ForEachItem

Read the full list on the Flowable tasks page.

Runnable tasks

Most data processing in Kestra is performed by Runnable tasks.

Unlike Flowable tasks, Runnable tasks perform the actual work — such as file system operations, API calls, or database queries. These tasks can be compute-intensive and are executed by workers.

Example runnable tasks include:

• io.kestra.plugin.scripts.python.Commands
• io.kestra.plugin.core.http.Request
• io.kestra.plugin.notifications.slack.SlackExecution

Core task properties

All tasks share the following core properties:

Property	Description
id	A unique identifier of the task
type	A full Java class name that represents the type of the task
description	Your custom documentation of what the task does
retry	How often should the task be retried in case of a failure, and the type of retry strategy
timeout	The maximum time allowed for the task to complete expressed in ISO 8601 Durations
runIf	Skip a task if the provided condition evaluates to false
disabled	A boolean flag indicating whether the task is disabled or not; if set to true, the task will be skipped during the execution
workerGroup	The group of workers (EE-only) that are eligible to execute the task; you can specify a workerGroup.key and a workerGroup.fallback (the default is WAIT)
allowFailure	A boolean flag allowing to continue the execution even if this task fails
allowWarning	A boolean flag allowing to mark a task run as Success despite Warnings
logLevel	Defines the log level persisted to the backend database. By default, all logs are stored. For example, restricting to INFO prevents DEBUG and TRACE logs from being saved.
logToFile	A boolean that lets you store logs as a file in internal storage. That file can be previewed and downloaded from the Logs and Gantt Execution tabs. When set to true, logs aren’t saved in the database, which is useful for tasks that produce a large amount of logs that would otherwise take up too much space. The same property can be set on triggers.

Dynamic vs. static task properties

Task properties can be static or dynamic. Dynamic properties can be set using expressions. To determine whether a property is static or dynamic, check the task’s documentation on the plugin’s homepage or in the UI by clicking on the documentation tab for the task.

Some properties are marked as not dynamic because they are complex types (e.g., maps, lists of strings, lists of maps). These act as placeholders for other dynamic properties.

For example, the runTasks property of Databricks’ SubmitRun is not dynamic because it is an array of RunSubmitTaskSetting.

Each RunSubmitTaskSetting contains its own properties, many of which are dynamic or placeholders for more complex types. Always drill down to the lowest level — most low-level properties are dynamic and can be templated using expressions.