Scheduling a workflow

A schedule trigger creates workflow runs on a recurrence you set. It can target Cloud or On this Mac. A poll trigger is cloud-only. See Running on your own machine instead for how a Desktop app claims a local scheduled run.

Setting the recurrence

From the workflow's editor, add a schedule trigger and pick a recurrence: hourly, daily, weekdays, weekends, or a custom rule if none of the presets fit. Daily and the day-of-week presets also take a time of day and a timezone. Custom lets you edit the RRULE directly. The beta supports hourly or daily frequency with INTERVAL, BYDAY, BYHOUR, and BYMINUTE; finite schedules and other RRULE options are rejected.

Alongside the recurrence, a schedule trigger also sets:

• Location — cloud workspace (default) or On this Mac, if a local repo is available to pick. Cloud executes the run without a Desktop app. On this Mac creates a run in the control plane, then waits for a signed-in Desktop app owned by the workflow author to claim it. A poll trigger has no Location picker; it is cloud-only.
• Repository — a cloud schedule works against a repo whose workspace is derived and warmed for you, nothing to provision by hand. An On this Mac schedule pins a repository from the Desktop that creates it. Any signed-in Desktop for the same owner can claim the run, and the run fails if that device cannot find a matching local clone.
• Arguments — fixed values for the workflow's declared inputs. A scheduled run always fires with these, since there's no one there to answer a prompt.
• If still running when triggered — controls how a due occurrence is handled while an earlier run from this trigger is non-terminal. The exact behavior is below.

Save runs the same setup checks as any other trigger before it goes live.

When the previous run is still active

• Skip this run does not create another run immediately. It holds the schedule cursor at the overdue occurrence. After the earlier run finishes, the accumulated window is processed by the missed-run policy below. This means the occurrence is deferred and classified later, rather than silently discarded at the moment it comes due.
• Queue after records each occurrence. Cloud runs are delivered one at a time, in order, after the prior run becomes terminal. Local runs are claimed in order, but the current Desktop claim path can deliver another run before the prior one finishes. Use Skip this run when overlapping local execution would be unsafe.

The missed-run policy

When the scheduler sees one or more overdue occurrences, the trigger's missed-run policy decides what happens to that window. This can follow a service interruption, or happen after Skip this run held the cursor while an earlier run was active:

• Run the latest occurrence, skip older ones (default) — only the newest missed slot actually fires; every older slot in the gap is recorded as a Missed row, never fired.
• Skip every missed occurrence — nothing in the gap fires; every slot in the gap is recorded Missed.
• Replay every missed occurrence — every slot in the gap fires, in order, as its own run.

After the window is processed, every occurrence has a run-history row, fired or not. Nothing from the window disappears silently.

This is per-trigger and schedule-only. A poll trigger has no recurrence slots to miss, so it isn't affected.