Recurring workflows run on a repeating schedule and are designed for ongoing processes such as collections, follow-up, reporting, and recurring outreach. They can collect data, make decisions, update stored state, and continue from one cycle to the next.
Unlike a simple time trigger, which runs once, the recurring schedule trigger runs repeatedly:
All times are set in a specific timezone so workflows run at the correct local time, including through daylight savings changes where applicable.
After each run completes, the system automatically schedules the next occurrence.
Each orchestration has a persistent data store — a shared state layer that remains available across recurring runs. This is what makes looping possible: one run can write data, and the next run can read it back.
| Action | What It Does |
|---|---|
| Store Write | Saves or merges data into the store. Use "merge" mode to update specific keys without overwriting everything, or "replace" mode to overwrite the entire store. |
| Store Read | Loads the current store data so downstream steps can use it (e.g., in templates, task agent instructions, or AI router context). |
| Store Clear | Wipes the entire store. Useful for end-of-cycle resets. |
When you use Store Read, the stored keys become available to every step that follows, similar to form data or call transcripts. Steps can reference those values in their configuration using template syntax such as {{accounts_queue}}.
Store Read keys are available as placeholders inside task agent instructions. For example, if Store Read loads the key accounts_receivable, you can reference it directly in the prompt:
Here are the current accounts receivable:
{{ accounts_receivable }}
Analyze the above data and identify any accounts overdue by more than 30 days.
If the stored value is a string, it is inserted as-is. If it is an object or array, it is inserted as formatted JSON. Any placeholder that does not match an available key is left unchanged.
This works for any key produced by a prior step, not just store data. Task agent outputs, form data, and other step results all flow through the same placeholder system.
When a task agent runs inside an orchestration, it automatically receives the Update Orchestration Store tool. This lets the AI write structured results back to the store during execution without requiring a separate Store Write step.
For example, a task agent that processes accounts receivable can update the store directly:
Here are the current accounts receivable:
{{ accounts_receivable }}
Process overdue accounts and update the store with the revised list using the update_orchestration_store tool.
The tool merges keys into the existing store while preserving unrelated keys, so downstream steps and future recurring runs see the updated data.
Note: The update_orchestration_store tool appears automatically when the task agent is running inside an orchestration. It is not available when the task agent runs standalone (e.g., from the Task Agents page or via API).
When you use Store Write as a separate orchestration step, you specify which keys to save and whether they should merge into the current store or replace it entirely. Use this when you want to write data from non-AI steps, such as form submissions or email collector results.
The email collector sends an outbound email and waits for a reply. When the recipient responds, the system parses the reply and stores the result.
The AI outcome router uses an LLM to classify data and route the workflow down different paths. Unlike a traditional rule-based branch, the AI router can interpret transcripts, summaries, and other unstructured context.
Each outcome branch works like a sub-workflow: you can drag actions into it from the palette, and they execute in sequence.
The for-each step iterates over an array from the data store or any prior step output and runs a set of nested actions per item. This is useful when you need to call a list of contacts, send emails to a batch, or process records one at a time.
accounts_receivable)item). Nested task agents can reference it through placeholders such as {{ item }}.| Mode | Behavior |
|---|---|
| Sequential | Runs nested steps for item #1, waits for full completion (including calls), then item #2, etc. One at a time. Best when each item's outcome affects the next, or when you need controlled pacing. |
| Batch | Queues all items at once as parallel orchestrator jobs. Each runs independently as soon as the next tick fires. Best for sending emails or SMS to a large list quickly. |
| Time-Delayed | Queues all items with a staggered delay between them. Item #1 runs immediately, item #2 after the configured delay, item #3 after double the delay, etc. Best for outbound calls where you don't want to overwhelm the system or hit rate limits. |
Drag steps into the for-each body on the canvas. These nested steps run once per item and receive the current item in their context.
For example, to call every account in a list:
accounts_receivableaccounts_receivable, item key: account, mode: sequential{{ account }} to prepare the callEach iteration receives:
{{ item_key }} (whatever you named it)_forEachIndex — the zero-based index of the current item_forEachTotal — total number of items being iteratedThese primitives are designed to work together:
The loop closes naturally: each run reads the store, performs work, writes updated state back, and the next scheduled run continues from that new state.