Create and assign a schedule¶

A schedule decides when work runs. You build the schedule once, then attach the packages, process maps or rules that should run on it — so the timing lives in one place instead of being repeated on every task.

Schedules are managed under Orchestration → Schedules.

The Schedules overview¶

The toolbar has two actions: Enable and Disable. Both act on the rows you tick, which is how you stop a schedule for a maintenance window without deleting it and losing what it was attached to.

Steps¶

1. Create the schedule¶

Select Create. A new schedule opens, enabled, belonging to one environment.

Name it for the rhythm rather than the contents — "Nightly warehouse load", "Hourly CRM sync". Several tasks will share it, and a name listing today's tasks ages badly.

Environment decides which environment's configuration the run uses. A schedule belongs to one; use separate schedules for Development, Test and Production.

2. Choose a frequency¶

Seven frequency types, each with a one-line description in the list:

Weekly is the common choice for anything with a business rhythm — a Monday-morning reload, a weekday-only sync:

Fill in the start date and start time as well as the recurrence. Until all of those are set, the schedule is incomplete and Save stays unavailable — hover it to see what is missing.

3. Optionally bound it to certain hours¶

Run only between specific hours limits the hours in which the schedule may start a run, with a From and a To time. It is the answer to "run every two hours, but never during the working day".

The window governs when a run may start, not how long it may take. It is offered on the Repeat every and Continuous frequencies.

4. Optionally compute the next run with SQL¶

The SQL-defined frequency exists for schedules no calendar expresses — the second banking day of the month, or the day after a source system's own close. The query returns the next run time.

Compute the next run with a query. It runs against the Timextender platform database, not your source systems.

That constraint matters: the query cannot look at your ERP to decide. It can read the platform database, including what previous runs did. The editor ships example queries you can copy, and a Test button that shows the next run time the query returns — always use it, because a query returning nothing produces a schedule that never fires. If it returns nothing you will see The query did not return a next run time.

Testing needs permission; without it you will see You do not have permission to test this schedule.

5. Attach the work¶

A schedule with no tasks does nothing. Add the packages, process maps or rules it should run, and set the execution mode that decides whether they run one after another or together.

Ordering matters more than it looks: several tasks on one schedule are the cheap way to sequence a nightly flow, but a process map is the better tool as soon as one step must not run when an earlier one failed. A schedule runs its tasks; it does not reason about dependencies between them.

6. Save¶

The schedule appears in the overview with its frequency and enabled state.

Best practices¶

Few schedules, many tasks. A handful of named rhythms that many tasks share is far easier to reason about than one schedule per task. When something must move, you move one schedule.

Disable rather than delete. Disabling keeps the attachments, so re-enabling restores the arrangement exactly. Deleting loses it.

Leave headroom between dependent schedules. If a 02:00 load feeds a 03:00 refresh, a load that occasionally takes seventy minutes will publish stale data silently. Express the dependency in a process map instead of trusting the gap.

Troubleshooting¶

The schedule is enabled but nothing runs. Check the attached packages are published, not drafts, and that the schedule has any tasks attached at all.

It runs, but at an unexpected hour. Timezone, or a run window that pushed the start.

A SQL-defined schedule never fires. Its query returns no next run time. Use Test in the editor to see what it returns.

Runs overlap. A Continuous or short-interval schedule whose work takes longer than the interval. Lengthen the interval, or bound it with Run only between specific hours.

Save is unavailable. Hover Save for the list. A start date and time are required alongside the recurrence, and Weekly needs at least one weekday.

Reference¶

Fields¶

The SQL-defined frequency¶

The query runs against the Timextender platform database and must return the next run time. The editor provides copyable examples and a Test action. A query that returns nothing yields a schedule that never fires, and that is not reported as an error at run time — which is why Test exists.

The rest of the schedules documentation¶

This page is the short path: create a schedule and attach work to it. Each part has its own page with the detail:

• The Schedules list — columns, the Next Run states, bulk enable/disable, Duplicate
• Creating a schedule — the Schedule tab — the seven frequencies, start date and time, the run window
• Adding tasks to a schedule — the Add-task picker, parallel vs sequential, extra parameters
• Schedule groups — running by hand, environment scoping, the Desktop redirect
• Schedule permissions — who can do what

Related¶

• Packages overview
• Interacting with process maps in Turnkey — for dependencies between steps
• Time zones