Scheduler Module

Pause a workflow on a timer, start it on a schedule, or book a future run with custom data.

The Scheduler Module adds five time-based Tasks to your Process. WaitFor and WaitUntil pause the current Session; ScheduleRecurring and ScheduleOnce start new Sessions on a recurring or one-time schedule; ScheduleReminder books a one-time future Session carrying custom data the classic appointment-reminder pattern. The Module does not require any Environment configuration.

How it works

The five Tasks fall into two groups:

• Pausing Tasks WaitFor and WaitUntil are Intermediate Catch Events. When the Token reaches one, the Session pauses; at the wake time it resumes from the same node and continues along the Sequence Flow.
• Scheduling Tasks ScheduleRecurring and ScheduleOnce are Start Events: alternative entry points into your Process. Each time the schedule is due, a fresh, independent Session starts. ScheduleReminder is a regular Task: it books one future Session (optionally with data) and lets the calling Session continue immediately.

All schedule times are in UTC. The platform checks due schedules about every 15 seconds, so anything you schedule fires within roughly 15 seconds of its due time. A Session started by a schedule begins on the Scheduler Channel unless you set the Task's Channel property. All five Tasks are generic they behave the same regardless of the Channel the Session runs on.

Deploying a new Process version updates your recurring and one-time schedules to match the diagram. It never cancels waits or reminders that are already in flight those belong to running Sessions and fire as planned. Every pending schedule, wait, and reminder is listed on the Scheduled Triggers page, where you can also fire, re-arm, or delete them.

Configuration

This Module does not require Environment configuration.

Everything is configured on the Task nodes themselves in the Process Editor.

Limits

• A single wait or reminder can reach at most 1 year into the future.
• Schedules fire within about 15 seconds of their due time do not rely on sub-second precision.
• A scheduled time up to 5 minutes in the past is accepted (clock tolerance) and fires immediately; anything earlier is rejected.

Tasks

WaitFor (Generic)

Pauses the current Session for a fixed duration "wait 24 hours, then send the follow-up". Add it as an Intermediate Catch Event.

Properties

Property	Type	Required	Example	Description
Amount	number	Yes	24	How many of the chosen unit to wait. Must be positive; the total wait (Amount × Unit) is capped at 1 year.
Unit	selection	Yes	Hours	Time unit applied to Amount. Options: Seconds, Minutes, Hours, Days, Weeks. Default: Hours.

Behavior

1. When the Token reaches this node, the Task computes the wake time the current time plus Amount × Unit and pauses the Session.
2. At the wake time the Session resumes from this node and the Token continues along the outgoing Sequence Flow.

Example

A welcome workflow sends a sign-up confirmation, then a WaitFor with Amount 24 and Unit Hours, then an onboarding tip message. A Session that reaches the wait on Tuesday at 10:00 UTC resumes on Wednesday at about 10:00 UTC and sends the tip.

tip

WaitFor is always relative ("24 hours from now"). If you need to wake at a specific moment "at 09:00 on December 31" use WaitUntil instead.

WaitUntil (Generic)

Pauses the current Session until a specific UTC datetime, then resumes. Add it as an Intermediate Catch Event.

Properties

Property	Type	Required	Example	Description
Wait until (UTC ISO-8601)	string	Yes	2026-12-31T09:00:00Z or {expiresAtUtc}	The UTC instant to resume at. Accepts an ISO-8601 datetime (2026-03-25T10:00:00Z), an RFC 1123 datetime, or a {variable} holding one. A time up to 5 minutes in the past is accepted and resumes immediately; the maximum is 1 year ahead.

Behavior

1. The Task resolves any {variable} in the field against the Session, then parses the result as a datetime.
2. The Session pauses at this node.
3. At the given instant the Session resumes from this node and the Token continues.

Example

A subscription workflow stores the expiry instant in expiresAtUtc = 2026-12-31T23:59:00Z. A WaitUntil node with Wait until {expiresAtUtc} pauses the Session until that moment; the next node then revokes the customer's access.

ScheduleRecurring (Generic)

A Start Event that begins a new Session of your Process on a recurring schedule every five minutes, hourly, daily, weekly, monthly, or any custom cron cadence.

Properties

Property	Type	Required	Example	Description
Schedule preset	selection	Yes	Daily	The cadence. Options: EveryFiveMinutes, EveryHour, Daily, Weekly, Monthly, CustomCron. Default: EveryHour. Daily, Weekly, and Monthly show Time of day; Weekly adds Days of week; Monthly adds Day of month; CustomCron shows Custom cron.
Time of day (UTC, HH:mm)	string	Yes, for Daily / Weekly / Monthly	09:30	UTC clock time the schedule fires, in HH:mm. Times use the 24-hour clock (type 17:00, not 5:00 PM). Default: 09:00.
Days of week	string	Yes, for Weekly	MON,WED,FRI	Comma-separated weekday tokens. Allowed (case-insensitive): MON, TUE, WED, THU, FRI, SAT, SUN. Default: MON,TUE,WED,THU,FRI.
Day of month (1-31)	number	Yes, for Monthly	1	Calendar day the schedule fires each month, 1–31. If a month has fewer days, the schedule simply skips that month. Default: 1.
Custom cron (UTC)	string	Yes, for CustomCron	0 9 * * MON	Standard 5-field cron expression minute, hour, day-of-month, month, day-of-week evaluated in UTC.
Channel (optional)	string	No	Chat	The Channel the new Session starts on. Letters, digits, and underscores only. Default: Scheduler.

warning

Days of week takes short uppercase tokens (MON, TUE, …) this is different from the Date Module, whose day-name fields take full English names like Saturday,Sunday. Don't mix the two formats; a full name here fails the Deployment with a clear error.

Behavior

1. When you deploy the Process, the schedule is validated an invalid time, weekday token, day of month, or cron expression fails the Deployment with a message naming the bad field.
2. At each due time the platform starts a fresh Session of the Process from this node.
3. Each Session is independent: no state is shared between fires, and a long-running Session does not delay the next fire overlapping runs are allowed.
4. If the schedule fails to start 10 times in a row, it is disabled so it stops failing on every fire; re-deploying the Process or Re-arm on the Scheduled Triggers page re-arms it.

Example

A report workflow should run at 09:00 UTC on Monday, Wednesday, and Friday. Set Schedule preset Weekly, Time of day 09:00, Days of week MON,WED,FRI, and deploy. Every Monday, Wednesday, and Friday at 09:00 UTC a new Session starts, fetches the data, and posts the report.

ScheduleOnce (Generic)

A Start Event that begins a new Session exactly once at a set UTC datetime, then switches itself off.

Properties

Property	Type	Required	Example	Description
Fire at (UTC ISO-8601)	string	Yes	2026-05-01T09:00:00Z	The UTC instant to fire, as an ISO-8601 datetime. Validated when you deploy: a time more than 5 minutes in the past, or more than 1 year ahead, fails the Deployment.
Channel (optional)	string	No	Chat	The Channel the new Session starts on. Letters, digits, and underscores only. Default: Scheduler.

Behavior

1. When you deploy the Process, the fire time is validated and the schedule is registered.
2. At the given instant, a fresh Session of the Process starts from this node.
3. After firing, the schedule disables itself it will not fire again. To re-arm it, set Fire at to a new future instant and deploy again.

Example

A marketing campaign should launch at 09:00 UTC on May 1, 2026. Set Fire at 2026-05-01T09:00:00Z and deploy. At that moment one Session starts and runs the campaign workflow; the schedule then stays off until you give it a new date and re-deploy.

ScheduleReminder (Generic)

Books a brand-new Session at a future time optionally carrying data while the current Session continues immediately.

Unlike WaitFor and WaitUntil, which pause the same Session, ScheduleReminder starts a separate Session that runs independently when its time arrives. The new Session is linked to the one that scheduled it, so the two appear grouped in Session Details and Logs.

Properties

Property	Type	Required	Example	Description
When should it fire?	selection	Yes	Before another date	How the fire time is decided. Options: After a delay (counts from now), At a specific date and time (an absolute instant), Before another date / After another date (offset from a datetime carried in a variable). Default: After a delay.
How much	number	Yes, for After a delay / Before another date / After another date	24	How many of the chosen unit. The total offset is capped at 1 year.
Unit	selection	Yes, for After a delay / Before another date / After another date	Hours	Time unit applied to How much. Options: Seconds, Minutes, Hours, Days, Weeks. Default: Hours.
Date and time	datetime	Yes, for At a specific date and time	2026-12-31T09:00:00Z	The exact fire moment, chosen with a date and time picker. Use the time-zone dropdown to type the local wall-clock time the value is stored in UTC.
Reference date variable	string	Yes, for Before another date / After another date	{appointmentTimeUtc}	The variable holding the reference moment. Accepts an ISO-8601 datetime (2026-03-25T10:00:00Z), an RFC 1123 datetime, or a {variable} holding one. The reminder fires How much × Unit before or after this moment.
Payload (JSON, optional)	JSON	No	{ "appointmentId": "{appointmentId}" }	JSON object whose properties become the starting variables of the new Session. Supports {variable} interpolation against the current Session. Leave empty to start the reminder with no inputs.
Channel (optional)	string	No	Chat	The Channel the reminder Session starts on. Letters, digits, and underscores only. Default: Scheduler.
Target process	selection	No	(leave empty)	Which Process and Environment the reminder starts. Picked with the Environment picker see Choosing the target below. Default: the same Environment the calling Session runs in.

Choosing the target

The Target process picker supports three modes:

1. Leave it empty the reminder starts another Session of the same Environment the calling Session runs in. This is the default and covers most cases.
2. Pick a specific Environment choose a Process and one of its Environments; the reminder starts that Environment's workflow. The target must be in the same Workspace anything else is rejected.
3. Match by name choose a target Process and enable Match by env name. When the Task runs, the platform picks the Environment of the target Process whose name matches the calling Session's Environment name so your development Environment books reminders into the target's development Environment, and production into production, without wiring each one by hand.

A broken target a missing Environment, a different Workspace, or no same-named Environment in the target Process is caught when you deploy, so you find out immediately instead of when the reminder silently fails to fire.

Behavior

1. When the Token reaches this node, the Task computes the fire time from the chosen mode (resolving any {variable}s). The result must be no more than 5 minutes in the past and no more than 1 year ahead, or the Session stops with an error.
2. It resolves the target Environment (see above) and resolves the Payload's {variable}s against the current Session.
3. It books the reminder and the calling Session continues immediately to the next node.
4. At the fire time a new Session of the target Environment starts, with the Payload's properties as its starting variables, linked to the originating Session in Session Details and Logs.

Example

A booking workflow stores appointmentTimeUtc = 2026-06-20T15:00:00Z and appointmentId = apt-381. A ScheduleReminder with When should it fire? Before another date, How much 1, Unit Days, Reference date variable {appointmentTimeUtc}, and Payload { "appointmentId": "{appointmentId}" } books a new Session for 2026-06-19T15:00:00Z. The booking Session continues and confirms the appointment; one day before the appointment the reminder Session starts with {appointmentId} = apt-381 and sends the reminder message.

warning

The Payload is resolved when the reminder is booked, not when it fires changes to the calling Session's variables after this node have no effect on the reminder. The reminder Session receives only the Payload; it does not inherit the caller's other variables.

Scheduled Triggers

Every pending fire in your Workspace recurring schedules, one-time schedules, paused waits, and booked reminders is listed on the Scheduled Triggers page, reachable from the sidebar. Each row is one scheduled trigger: a record of when something fires next and what happens when it does.

All five Scheduler Tasks create triggers, in two ways:

• ScheduleRecurring and ScheduleOnce create one trigger per node when you deploy the Process (Lifecycle Static). Re-deploying updates the trigger to match the diagram.
• WaitFor, WaitUntil, and ScheduleReminder create a trigger while a Session runs when the Session pauses at the wait, or books the reminder (Lifecycle Dynamic). A Dynamic trigger fires once and is then removed from the list.

Fields

Field	Description
Id	Shortened trigger id click it to copy the full id.
Kind	What firing does: Start begins a new Session (schedules and reminders); Resume wakes the paused Session of a WaitFor or WaitUntil.
Lifecycle	Who owns the trigger: Static (created by Deployment for ScheduleRecurring / ScheduleOnce) or Dynamic (created by a running Session for WaitFor, WaitUntil, ScheduleReminder).
Origin	The Process and Environment the trigger belongs to where the node lives.
Target	The Process and Environment a Start trigger starts its Session in. Differs from Origin only for a ScheduleReminder with a Target process; shows — for Resume triggers.
Node	For a Static trigger, the id of the node in the diagram that created it. A Dynamic trigger instead shows what booked it (wait-for:, wait-until:, or schedule-reminder:) followed by the id of the Session that booked it.
Cron / one-shot	The recurring cron expression, or the one-time fire moment in UTC.
Next fire	When the trigger fires next. The list is sorted by this column by default.
Last fire	When the trigger last fired successfully.
Enabled	Whether the trigger fires when due. A one-time schedule that has already fired, or a schedule whose node was removed from the diagram, shows as disabled.
Failures	Consecutive failed starts since the last success. After 10 failures in a row the trigger is disabled automatically re-arm it or re-deploy the Process to retry.

Columns support sorting and per-column filters; use the checkboxes to select several rows and act on them together.

Actions

Each row's menu (⋯) offers Re-arm, Fire now, and Delete; the buttons above the list run the same actions on every selected row. All three require the Member role or higher in the Workspace see Collaboration.

• Re-arm recomputes the next fire time from the trigger's stored schedule, re-enables it, and resets the failure count. Only Static triggers can be re-armed, and a one-time schedule only while its fire time is still in the future for a fire time that has passed, set a new Fire at in the diagram and re-deploy instead.
• Fire now makes the trigger fire within about 15 seconds, regardless of its scheduled time. A recurring schedule then continues on its normal cadence; a one-time schedule or a Dynamic trigger is consumed by the early fire. Handy for testing a scheduled workflow without waiting for its due time.

Delete a trigger

1. Navigate to Scheduled Triggers from the sidebar.
2. Open the row menu (⋯) on the trigger and choose Delete or tick the checkboxes of several rows and click Delete selected.
3. Click Delete in the confirmation dialog.

danger

Deleting a trigger is permanent. Deleting a Resume trigger leaves its paused Session waiting forever the WaitFor or WaitUntil never wakes. To stop a recurring or one-time schedule for good, remove the node from the diagram and re-deploy instead of deleting the row.

Common recipes

Send a daily usage digest

Run a fresh Session every morning that fetches yesterday's numbers and mails them out.

1. ScheduleRecurring Schedule preset Daily, Time of day 06:00. Every day at 06:00 UTC a fresh Session starts.
2. HttpTask Method GET, URL https://api.example.com/stats/daily, response stored in the variable stats.
3. HttpTask Method POST to your email provider's API, with a body template that includes {stats}. The Session ends after the send.

Remind a customer the day before their appointment

A chat booking workflow validates the appointment date, books a reminder Session for 24 hours before it, and confirms.

1. Get Date (Date Module) Operation Current time, Format iso, output variable now the lower bound for the validation.
2. InputTask collects the requested appointment date into the variable appointmentInput.
3. Check Date Operation Validate, Input {appointmentInput}, Min date {now}, output variable appointmentTimeUtc. Label the three outgoing Sequence Flows valid, invalid, and outOfRange; on valid the normalized ISO-8601 UTC value is written to appointmentTimeUtc.
4. ScheduleReminder (valid branch) When should it fire? Before another date, How much 1, Unit Days, Reference date variable {appointmentTimeUtc}, Payload { "appointmentId": "{appointmentId}", "phone": "{phone}" }. The reminder Session uses the Payload to send the reminder message.
5. OutputTask (valid branch) confirms the booking to the customer.
6. OutputTask (invalid branch) replies that the date couldn't be read and asks for it again; on the outOfRange branch, a third OutputTask explains the date is already in the past and asks for a future one.

Resume work at the start of the next business day

Defer a non-urgent action that arrives on a weekend until the next working day, at the same clock time.

1. Get Date (Date Module) Operation Current time, Format iso, output variable now.
2. Transform Date Operation Next business day, Input date {now}, If already a business day same (the default), output variable resumeAt. A request arriving Saturday at 09:00 UTC gets {resumeAt} = Monday 09:00 UTC; one arriving on a working day keeps {resumeAt} = the current time, so nothing is deferred.
3. WaitUntil Wait until {resumeAt}. A weekend arrival pauses the Session until Monday; a weekday arrival resumes immediately.
4. HttpTask performs the deferred action on Monday morning.

Best practices

1. Think in UTC. Every schedule time is UTC when your audience lives in another time zone, compute times with the Date Module's Transform Date (Operation Convert time zone) and display them with Extract Date (Operation Format text).
2. Relative waits → WaitFor, absolute waits → WaitUntil. "In 24 hours" is WaitFor; "at 09:00 on December 31" is WaitUntil with an ISO-8601 instant or a computed {variable}.
3. Design scheduled workflows to tolerate a duplicate run. In rare cases such as a platform restart at exactly the wrong moment a due schedule can fire twice. Make the actions it triggers safe to repeat.
4. Forward everything the reminder needs in the Payload. A reminder Session does not inherit the caller's variables pass the ids, names, and numbers it needs explicitly.
5. Prefer presets over custom cron. The Daily / Weekly / Monthly presets are validated field by field with clear Deployment errors; reach for CustomCron only when no preset fits.

Error codes

Code	Name	Description
3005	TaskInvalidData	An amount, unit, datetime, weekday token, or cron expression is invalid, or a reminder's target Environment cannot be resolved. See full details
4001	ModuleException	The platform could not register the wait or reminder. The Session stops with this error instead of waiting forever. See full details