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.

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 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.

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. InputTask — collects the requested appointment date into the variable appointmentInput.
2. DateValidationGuard (Date Module) — validates {appointmentInput} and stores the normalized ISO-8601 UTC value in appointmentTimeUtc; the Token leaves on valid or invalid.
3. 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.
4. OutputTask — confirms the booking to the customer; on the invalid branch, a second OutputTask asks for the date again.

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. Now (Date Module) — Format iso, output variable now.
2. NextBusinessDay — Input date {now}, If already a business day next, output variable resumeAt. A request arriving Saturday at 09:00 UTC gets {resumeAt} = Monday 09:00 UTC.
3. WaitUntil — Wait until {resumeAt}. The Session pauses over the weekend.
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 or display times with the Date Module's ConvertTimeZone and FormatDate Tasks.
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