Scheduled Runs
A scheduled run fires a flow on a timer. No customer, no message — just the flow, running because the clock said so.
What a scheduled run does
One fire produces one execution of the flow. What that execution does is entirely up to the flow: query a database, summarise yesterday's conversations, call an API, send a message.
Because there's no incoming customer message, the flow starts from its
flow variables rather than from question. Write the first
node's prompt accordingly.
Setting a schedule
Two trigger types:
| Type | Fires | You configure |
|---|---|---|
| One-shot | Exactly once, at a time you pick | The date and time |
| Recurring | Every time a schedule pattern comes round | The pattern (for example, every day at 09:00) |
A one-shot fires exactly once, whether it reaches its time naturally or you trigger it early with Fire Now. Firing early consumes the schedule, so it can't go twice.
A recurring automation keeps going until you pause it, it hits a maximum number of runs, or it passes an expiry date — both optional, and both worth setting on anything experimental.
Time zones
Every automation carries a time zone. "09:00" means 09:00 there — Europe/Istanbul,
America/New_York, whatever you picked — not on the server and not in your browser.
This matters more than it sounds:
- Daylight saving is handled for you. A 09:00 daily job stays at 09:00 through the clock change.
- Pick the audience's zone, not yours. A campaign for Turkish customers should fire in
Europe/Istanbuleven if you're managing it from Berlin. - Check it when a job fires at the wrong hour. A three-hour offset is almost always a time-zone setting, not a bug.
Lateness
Catch-up window — how late a fire can be and still run. If the system was delayed past the window, that fire is skipped rather than running stale. Raise it for jobs that tolerate late delivery; lower it for anything time-sensitive, where a digest arriving four hours late is worse than not arriving.
If a fire is still running when the next one is due, the new fire is deferred rather than started alongside — so a long-running job doesn't stack copies of itself.
Pausing and resuming
| Status | Meaning |
|---|---|
| Active | Armed. It will fire |
| Paused | You paused it. Resume to re-arm |
| Paused by system | Flowera paused it for safety — see Failure handling |
| Completed | A one-shot that fired successfully. Terminal |
| Cancelled | Stopped for good. Terminal |
Pausing is reversible and takes effect immediately; a fire that's already running finishes. Cancelling is not reversible — you'd recreate the automation instead.
Pause anything you're about to change. Editing a live schedule while it's mid-fire is how you get a half-configured run.
What the flow receives
The flow starts with whatever flow variables the automation supplies, and nothing else. There is
no customer, no session history, no question.
Design for that: a scheduled flow's first node should read from flow state or fetch what it needs with an HTTP node, rather than expecting an incoming message.
For the trigger's in-flow configuration, see Scheduled run trigger.
Related
- Batch runs — one fire, many recipients
- Monitoring — checking it actually fired
- Failure handling — when it doesn't