Running Multiple Schedules on One Trigger

A single Schedule trigger in Spojit can hold several cron schedules at once, each with its own IANA timezone, so one workflow can fire at multiple times without duplicating it.

Overview

The Schedule trigger starts a workflow on a recurring calendar using a 5-field Unix cron expression and an IANA timezone such as Australia/Sydney or America/New_York. Most people set one expression and move on, but the trigger is not limited to a single entry. You can add multiple schedules to the same trigger, and Spojit fires the workflow whenever any one of them is due. This lets you express patterns that a single cron line cannot, like "weekday mornings in Sydney plus a separate Monday-only run for the US team," from one trigger on one workflow.

Each schedule you add is independent: it has its own cron expression and its own timezone, and it evaluates against the wall-clock time of that zone. When the workflow runs, the trigger output is the same regardless of which schedule fired, so your downstream nodes do not need to branch on which schedule was responsible. The output is { scheduledAt }, the timestamp at which the run was due. This guide explains how to add and manage several schedules on one trigger, how timezones interact, and the edge cases that catch people out.

Steps

To add more than one schedule to a Schedule trigger, open your workflow in the Workflow Designer and follow these steps.

Click the Trigger node on the canvas to open its properties panel on the right.
Set Trigger Type to Schedule if it is not already selected.
In the first schedule row, enter a cron expression in the Cron expression field and pick a zone in the Timezone field. For example, 0 9 * * 1-5 with Australia/Sydney runs at 9:00 AM Sydney time, Monday through Friday.
Click Add schedule to create a second row. Enter a separate cron expression and timezone for it, for example 0 6 * * 1 with America/New_York to run at 6:00 AM New York time every Monday.
Repeat for any further schedules you need. Each row stands on its own.
To remove a schedule, click the remove control on its row. At least one schedule must remain for the trigger to be valid.
Save the workflow. Once the workflow is enabled, Spojit fires it whenever any of the listed schedules is due.

How Cron and Timezones Work Together

Each schedule uses a standard 5-field cron expression in the order minute, hour, day-of-month, month, day-of-week. A few common examples:

0 9 * * 1-5 runs at 9:00 AM on weekdays (Monday to Friday).
*/15 * * * * runs every 15 minutes.
0 0 1 * * runs at midnight on the first day of every month.
30 8 * * 1 runs at 8:30 AM every Monday.

The Timezone field on each row is an IANA zone name, not a fixed UTC offset. Because Spojit evaluates each cron expression against the wall-clock time of its zone, a schedule that says 9:00 AM stays at 9:00 AM local time even across daylight saving changes. That is why putting the timezone on each schedule row matters: a Sydney 9:00 AM schedule and a New York 9:00 AM schedule are different absolute moments, and keeping them as two rows on one trigger keeps each one anchored to its own region.

When to Use Multiple Schedules Instead of Multiple Workflows

Reach for multiple schedules on one trigger when the same logic should run at different times or in different regions and the downstream steps are identical. A daily report that goes out for two regional offices, an inventory sync you want to run both early morning and mid-afternoon, or a reminder that should fire on weekday mornings plus once on the weekend are all good fits. You keep one workflow to maintain, one execution history to read, and one place to edit the steps.

If the work itself differs by time of day (for example a light morning sync versus a heavy nightly export), build separate workflows instead, since the downstream nodes are not the same. You can still factor shared logic into a reusable child with the Subworkflow node so both schedules call the same underlying steps.

Tips

Use Miraxa, the intelligent layer across your automation, to draft schedules from plain language. A prompt like "Add a schedule that runs at 9 AM on weekdays in Australia/Sydney and a second schedule at 6 AM Mondays in America/New_York" sets up both rows, then fine-tune them in the properties panel.
If you are unsure of the exact IANA name for a region, the Date & Time connector's list-timezones tool returns the valid zone identifiers you can paste into the Timezone field.
Read {{ trigger.scheduledAt }} downstream if a step needs the due time, for example to label a report with the date it was generated.
Keep schedule rows few and meaningful. Two or three well-named patterns are easier to reason about than a long list of near-duplicate rows.

Common Pitfalls

Leaving the Timezone field on its default when a row is meant for a specific region. Every schedule row carries its own zone, so set it explicitly on each one rather than assuming all rows share a timezone.
Expecting a way to tell which schedule fired a given run. The trigger output is the same { scheduledAt } for every schedule, so do not write logic that branches on the schedule. Branch on the time inside {{ trigger.scheduledAt }} instead if you truly need different behavior.
Daylight saving surprises. Because cron is evaluated against local wall-clock time, a run scheduled inside the hour that a region skips or repeats at a DST change may run zero or two times that day. Avoid scheduling critical runs in the early-morning DST window for that zone.
Forgetting to enable the workflow. A Schedule trigger only fires when the workflow is enabled. Saving the schedules is not enough on its own.