Scheduled delivery
A schedule delivers saved reports and datasets by email on a recurrence. It is the difference between reporting someone has to remember to run and reporting that simply arrives.
Each schedule shows its recurrence, how many recipients it has, when it next fires and whether it is enabled.
What a schedule holds
Section titled “What a schedule holds”Deliverables — the reports and datasets to send. A schedule can carry several of each, so one Monday-morning email can hold the whole operations pack rather than four separate messages. Reports are delivered as PDF; for each dataset you choose the format, within what its kind allows: CSV, Excel or PDF.
Recurrence — daily, weekly (pick the weekday) or monthly (pick the day of the month), each with a time of day.
Recipients — who receives it.
Enabled — a disabled schedule keeps all its settings and never fires. Use it to pause a delivery without rebuilding it.
The window stays relative
Section titled “The window stays relative”This is the part worth understanding, because it is what makes a schedule set-and-forget.
A schedule does not freeze the period. It stores nothing about the data and no date range of its own; it triggers exactly the same generation path as the export button, and the window is resolved at the moment each delivery is produced.
So a dataset scoped to “last 7 days” means the last seven days of every delivery. Configure it once in July and the January email is still about the week that just ended. Nothing decays, and nobody has to go back and roll the dates forward.
The corollary: if you need a fixed window — a specific audit quarter that must not move — set an absolute global period on the report itself, and schedule that.
Time of day, and clusters
Section titled “Time of day, and clusters”A schedule fires at its configured time in the system’s local timezone, and the same local time on every node of a cluster. In a high-availability deployment only the leader runs the tick, so a report is generated and sent once, not once per node.
Sending on demand
Section titled “Sending on demand”Send now delivers a schedule immediately without waiting for its next run, and without disturbing the recurrence. It is the right way to check that recipients and formats are correct before leaving a schedule to run on its own.
The result is reported back plainly: how many recipients it went to, and — if anything could not be produced — how many items were skipped and why. A delivery that partly fails does not fail silently.
Auditing
Section titled “Auditing”Schedule activity lands in the audit trail like any other action: creation, changes, deletion and each delivery. “Who set this up and when did it last go out” is answerable after the fact rather than a matter of memory.
Permissions
Section titled “Permissions”Managing schedules needs reports:schedule. Because a schedule sends data out of the
product by email, treat that permission the way you treat reports:export — it is
the other door through which data leaves.
Common scenarios
Section titled “Common scenarios”Weekly operations digest. One schedule, weekly on Monday at 08:00, carrying one report with a global relative period of 7 days.
Monthly compliance pack. Monthly on the 1st, carrying the review report. If the pack must cover an exact month rather than a rolling 30 days, give the report an absolute period and update it each cycle — or accept the rolling window and say so on the cover.
A spreadsheet for someone who lives in Excel. A dataset delivered as XLSX, daily, with no report attached at all. Schedules are not report-only.