Schedules

Schedules are stored, not run

You can create schedules today through the API, and they are kept with the template, but nothing executes them yet. The server-side runner is a later release, and the app has no page for schedules.

If you are planning a process around a nightly import, plan for somebody to run it for now: every import today runs in the app, started by a person with it open. A schedule that exists but does not fire is worse than no schedule at all if you assumed otherwise.

Why they exist already

A template is meant to outlive the person who built it, and “run this on the first of the month” belongs with the template, not somewhere separate. Storing schedules now means:

• What a schedule says — when, in which timezone, on or off — is settled before anything depends on it.
• When the runner ships, existing templates already say what they wanted.

What a schedule holds

Name	What this run is.
Cron	A five-field cron expression: 0 2 * * * is 2am daily. Sloose checks only that it has five fields.
Timezone	An IANA zone, Australia/Sydney. Defaults to UTC, and is stored as written.
Enabled	Off without deleting it.
Source configuration	Where the rows will come from when it fires.

Set the timezone deliberately. A nightly job defaulting to UTC runs at lunchtime in Sydney, which is exactly the sort of thing nobody notices until it matters.

A schedule belongs to one template. Anybody who can see the template can list its schedules, whoever may change the template can add, change and delete them, and deleting the template deletes its schedules with it.

Where the rows will come from

This is the part that makes a scheduled import different from an interactive one. Today, somebody brings a file. A scheduled run has nobody to bring it, so the schedule carries a source configuration saying where to fetch from.

For now that is any JSON object, kept as it was sent: nothing reads it yet, so what it has to hold is not settled. Until the runner exists, treat it as recorded intent rather than a working connection.

Limits

Your plan will cap how many schedules an organisation can hold, and whether scheduled imports are available at all: zero on Free and Team. Neither is checked yet. A schedule is stored and never run, so nothing counts it against the plan until the runner ships. Then a schedule past the cap will be refused with LIMIT_SCHEDULES, and one on a plan without the feature with FEATURE_SCHEDULED_IMPORTS. See Plans and limits.

What the design already settles

None of this runs yet. Two things are already decided for when it does:

• A scheduled run is authorised the same way an interactive one is. Before its first row, the plan’s runs for the month and the rows one run may write are checked; what the run writes is then checked row by row as it goes, against the rows one run may write.
• It appears in the same run history, with mode: server rather than widget, so you do not have two places to look.