Scheduled Reports

The report picker is the reports catalogue itself — every title the Reports module can build, grouped by the section you would find it under. Choosing from a section is how the system knows which report you mean: a few titles exist in more than one place, and a schedule that paired the wrong two would send attendance records under a payroll heading. That pairing is checked when you save, when you edit, and again on every run.

Separately from the frequency, you choose the period the report covers: the previous day, the previous week, the previous month, month to date, or a rolling 7 or 30 days. Keeping the two apart matters — a weekly schedule might reasonably want last week, or the month so far, and guessing on your behalf is how a report quietly answers a different question.

Daily, weekly and monthly each carry the anchor they need: a time of day, a weekday, or a day of the month. A scheduler pass runs every fifteen minutes and fires only what is due, so a schedule set for 07:00 arrives at 07:00 in your organisation's timezone — not at a fixed hour chosen for somebody else's.

The timetable does not drift. Each next run is worked out from the run that was due, not from the moment the work happened, so a busy pass that starts late never makes every future run late. A schedule paused for three months fires once when you switch it back on and returns to its rhythm — it does not deliver ninety back-dated reports covering periods you have already seen.

Each run generates the report and attaches it as a CSV — byte for byte the file the Reports module downloads, so the copy in someone's inbox and the copy on your screen are the same document. The message body carries the first hundred rows as a table, the period covered, and the report's own summary figures.

Recipients are ordinary email addresses, validated when you save: lowercased, de-duplicated, and refused one by one with the offending address quoted so a typo takes a second to find rather than a hunt through twenty entries. Mail is sent under the sender display name from your organisation's Email Domain Setting.

A run records each recipient individually. If two addresses receive the report and a third bounces, the run is marked partial — not success, and not failure — and the two who received it are never contacted again. A retry sends only to the addresses still outstanding, up to three attempts, backing off in between.

Where outgoing email is not configured, the run says so in plain words and is recorded as a failure. It is not recorded as a success with nothing sent.

Every run writes one row: the report, the occurrence it was due at, the period it covered, how many rows it produced, its outcome, the recipients it reached and the ones it did not, any error, and when the next attempt is due. Rows are written by the scheduler and are not editable — a delivery outcome somebody typed in by hand is not evidence of anything.

Run due now fires everything currently due for your organisation using the very same code path the scheduler uses, and answers with counts: how many were delivered, how many partial, how many failed. If nothing is due, it says so rather than pretending to have done work.

Each due occurrence is claimed in the database before any work begins, and the claim is enforced by a uniqueness rule on the schedule and the occurrence together. A second worker — or the same worker restarted halfway through a send — cannot claim an occurrence that is already claimed.

That is what makes overlapping scheduler passes, restarts and retries safe: the guarantee is in the database, not in code that hopes to run only once.