Skip to main content
Every task in a flow definition has an execution_type that controls when it runs once its step is reached. There are four models — and because runs are durable, a task can safely wait hours or days without losing progress.
execution_typeBehavior
immediateRun right away (default)
scheduledWait for a delay, a fixed time, or the next cron occurrence
windowedRun only inside a recurring time window
signaledWait for an external signal, with a timeout
Every type except immediate requires an execution_config — omitting it is a validation error.

​
Immediate

The default. The task executes as soon as its step starts. You can omit execution_type entirely. 
{
  "task_id": "fetch_lists",
  "task_name": "Fetch contact lists",
  "platform_id": "five9",
  "service_id": "configuration_service",
  "action_id": "five9__configuration_service__get_lists",
  "execution_type": "immediate",
  "parameters": {"list_name": "prospects"}
}

​
Scheduled

Delays execution using one of three schedule_type variants:
schedule_typeConfig fieldBehavior
delaydelayWait a fixed duration (e.g., "30s", "5m", "2h"), then run
fixedrun_atWait until a specific ISO 8601 datetime, then run
croncronWait until the next occurrence of a cron expression (evaluated in UTC), then run
{
  "task_id": "morning_report",
  "task_name": "Run daily report",
  "platform_id": "five9",
  "service_id": "configuration_service",
  "action_id": "five9__configuration_service__run_report",
  "execution_type": "scheduled",
  "execution_config": {
    "schedule_type": "cron",
    "cron": "0 9 * * *"
  },
  "parameters": {"report_name": "daily_summary"}
}
A delay variant looks like {"schedule_type": "delay", "delay": "30m"}; a fixed variant looks like {"schedule_type": "fixed", "run_at": "2026-08-01T09:00:00Z"}.
A cron scheduled task fires once, at the next occurrence within its execution. To run an entire definition on a repeating cadence, use a scheduled job instead.

​
Windowed

Restricts execution to a recurring time window — for example, only calling prospects during business hours. The config takes a timezone, a window with allowed days plus start_time/end_time (24-hour "HH:MM"), and an outside_window policy:
outside_windowBehavior when triggered outside the window
schedule_nextWait until the window next opens, then run (default)
skipReturn a skipped result ({"_skipped": true, "reason": "outside_window"}) immediately
{
  "task_id": "business_hours_add",
  "task_name": "Add records during business hours",
  "platform_id": "five9",
  "service_id": "configuration_service",
  "action_id": "five9__configuration_service__add_to_list",
  "execution_type": "windowed",
  "execution_config": {
    "timezone": "America/New_York",
    "window": {
      "days": ["monday", "tuesday", "wednesday", "thursday", "friday"],
      "start_time": "09:00",
      "end_time": "17:00"
    },
    "outside_window": "schedule_next"
  },
  "parameters": {"list_name": "outbound", "records": []}
}

​
Signaled

Pauses the task until an external signal arrives — a webhook callback or a polled condition — or a timeout elapses:
FieldDescription
signal_typewebhook (default) or polling
timeoutHow long to wait (e.g., "1h", "24h")
on_timeoutWhat to do if no signal arrives: continue (default), abort_step, or abort_execution
on_timeout_outputWith on_timeout: continue, the output the task returns on timeout
{
  "task_id": "wait_for_approval",
  "task_name": "Wait for manager approval",
  "platform_id": "getdialed",
  "service_id": "utils",
  "action_id": "getdialed__utils__echo",
  "execution_type": "signaled",
  "execution_config": {
    "signal_type": "webhook",
    "timeout": "1h",
    "on_timeout": "continue",
    "on_timeout_output": {"approved": false}
  }
}
Timeout behavior in detail:
  • continue — the task resolves with on_timeout_output and the flow proceeds; downstream expressions can branch on it (e.g., an exit condition checking {{approval.wait_for_approval.output.approved}} == false).
  • abort_step — the task resolves with an error result, subject to its on_failure policy.
  • abort_execution — the whole execution fails.
Execution models compose with the rest of the task surface: a windowed task can still be batched, and any model’s outcome can drive step exit conditions.