Schedule jobs#

Timberline ships one schedule, deliberately switched off.

Property	Value
Name	Board Packet Delivery
State	disabled
When	`0 8 * * 4`, 08:00 every Thursday
Jobs	Board Packet, Divisional Packet
Hold for delivery	off
Parameter overrides	none

It is the demo's answer to "the board pack goes out every Thursday morning": two jobs on one schedule, so one entry drives the whole delivery rather than two schedules that can drift apart.

It ships disabled on purpose. A committed demo store that starts mailing on its own is a bad default. If you want to show a scheduled run, enable it deliberately, and disable it again afterwards, or it fires on the next Thursday.

Scheduling a job#

Open the job, or go to the scheduling screen, and create a schedule.
Give it a cron expression. Reportworq uses 5-field cron, minute, hour, day of month, month, day of week. 0 8 * * 4 is 08:00 on Thursdays.
Add the jobs. One schedule can carry several, which is the useful part: a delivery that spans three jobs stays together.
Optionally set parameter overrides, so the scheduled run uses different values from an ad-hoc run, a scheduled month-end run pinned to the closed period, for example. Timberline does not use this, but it is the reason parameter overrides exist.
Decide on hold for delivery (below).
Enable it.

Demo it safely: hold for delivery#

Hold for delivery is the setting to reach for when demonstrating a schedule. The run happens on time, the output is produced, and delivery waits for a human to release it from Activity.

That gives you a scheduled run you can talk over, "it ran at eight this morning, here is what it produced, and nothing has gone out yet", without committing to the send. It is also a genuinely good production pattern for a first month: schedule it, hold it, review it, release it, and only then let it go automatic.

Timberline's schedule has it off, so enable it before enabling the schedule if you want the safe path.

Campaign automation is a different thing#

Do not conflate the two. Job schedules run content on a clock. Campaign automation runs actions against a campaign, and its triggers are richer.

The Segment & Channel Budget Input campaign carries ten automation tasks using four trigger shapes:

Trigger	Tasks	Behavior
Schedule: `0 8 * * *`	contributor invitation, approver invitation	invite daily at 08:00
Schedule, no cron set	the two reminders, stop campaign, auto archive	armed, not clocked
Form status change	contributor workflow, approver workflow, the `FixedCosts` export	fire the moment a form moves state
No trigger	the `Plan1` export	run on demand

The teaching point is that the same action means something different depending on when it fires. The Plan1 export has no trigger and excludes unapproved data, it is the end-of-cycle export. The FixedCosts export fires on every form status change and includes unapproved data, it keeps the model warm while contributors are still working. See Export campaign data.

A caution for demo stores: the invitations fire at 08:00 daily, so a demo that wants an invitation now must trigger it rather than wait. And leave auto_archive disabled, enabling it would archive the campaign and refresh its forms, which destroys the demo state.