Schedule Trigger
The Schedule Trigger starts a workflow on a timetable. Open the node in the builder and define one or more Trigger Rules; the workflow runs whenever any rule fires, as long as the version that carries the trigger is Active.
Schedules are kept by the platform's scheduler service, not by the workflow engine: a saved and activated schedule fires on time whether or not anyone has the builder open, and editing a rule takes effect as soon as the workflow is saved and the version is active — there is nothing to restart.
Trigger Rules
Each rule has a Trigger Interval. The fields below it change with the interval you pick:
| Trigger Interval | Fields | Example |
|---|---|---|
| Seconds | Seconds Between Triggers (1–59) | every 30 seconds |
| Minutes | Minutes Between Triggers (1–59) | every 15 minutes |
| Hours | Hours Between Triggers (1–23), Trigger at Minute | every 6 hours at minute 30 |
| Days | Days Between Triggers (1–31), Trigger at Hour, Trigger at Minute | every day at 09:00 |
| Weeks | Weeks Between Triggers, Trigger on Weekdays, Trigger at Hour, Trigger at Minute | every 2 weeks on Monday and Wednesday at 08:15 |
| Months | Months Between Triggers, Trigger at Day of Month, Trigger at Hour, Trigger at Minute | every 3 months on the 15th at 06:00 |
| Custom (Cron) | Expression | 0 9 * * 1-5 (weekdays at 09:00) |
Click Add Rule for additional rules — for example one rule for weekday mornings and another for a monthly report. Each rule shows a one-line summary ("Every 2 weeks on Monday at 08:15") and flags values outside the allowed ranges.
Custom (Cron) accepts a standard 5-field expression (minute hour day-of-month month day-of-week) or a 6-field one with seconds first. The node shows the expression in words ("Every minute", "At 09:00, Monday through Friday") as you type, and "Invalid cron expression" when it cannot be read. crontab.guru is a handy reference.
A Months rule that names a day the month does not have (the 31st in April) skips that month. Intervals that plain cron cannot express exactly — every 3 days, every 2 weeks, every 7 hours — are honoured as written: the scheduler counts them from the moment the schedule was activated.
Timezone
Timezone sets the zone every rule is evaluated in (default UTC). Pick any IANA zone from the searchable list; each entry shows its current UTC offset so, for example, Asia/Kolkata (UTC+05:30) and Asia/Calcutta are easy to tell apart. Daylight-saving changes are handled by the zone: a rule for 09:00 in America/New_York fires at 09:00 local time all year.
Next runs
Under the rules the node lists the Next runs — the next five times the schedule would fire, in the chosen timezone, as computed by the scheduler for exactly the rules on screen. It updates as you edit, so you can check a cron expression or a timezone before saving.
Missed executions
If the scheduler was unavailable at a planned time — a maintenance window, for example — If Execution Is Missed decides what happens when it is back:
- Don't Run Missed Executions (default) — skip and wait for the next planned time.
- Run the Most Recent Missed Execution — run once for the latest missed time, then continue on schedule. Earlier missed times are never replayed.
Missed Execution Grace Period (Seconds) is how late a run may start and still count as on time; 0 uses the service default.
What a scheduled run receives
The trigger node outputs one item describing the planned fire time, in the schedule's timezone, so later nodes can use it in expressions:
| Field | Example |
|---|---|
timestamp | 2026-03-10T09:00:00.000+05:30 |
Readable date | March 10th 2026, 9:00:00 am |
Readable time | 9:00:00 am |
Day of week | Tuesday |
Year | 2026 |
Month | March |
Day of month | 10 |
Hour | 09 |
Minute | 00 |
Second | 00 |
Timezone | Asia/Kolkata (UTC+05:30) |
In the Runs list, scheduled runs are filtered under the Schedule trigger type, and a run's details show the planned time as well as when it actually started.
Activation and editing
- Schedules fire for the Active version only. Saving a draft with a different rule does not change what is live until that version is activated.
- Activating a different version moves the schedule to that version; deactivating the workflow pauses it. A schedule that is paused does not make up the runs it missed when it is resumed — it continues from the next planned time.
- Deleting the workflow removes its schedules.
- To test the workflow without waiting for the next planned time, click Run in the builder; a manual run uses the current moment as the fire time.
Troubleshooting
- Nothing fires — check that the version with the Schedule Trigger is Active (Versions panel) and that the Next runs preview shows upcoming times. A rule with an error (shown in red under the rule) is not scheduled until it is fixed.
- Fires at the wrong hour — check the Timezone field; rules are evaluated in that zone, not in your browser's.
- Two rules fire at the same moment — one run starts per rule. If both rules describe the same moment, two runs start.