Scheduled reports

A scheduled report is one definition: what is sent, in which format, to whom and when. The server produces and sends it itself, on its own clock, with nobody present.

It lives in settings, under Scheduled reports, and is restricted to administrators: deciding what leaves the organization by mail on a timer is not an operator's call.

What can be sent

Subject	What is produced	Needs a target
Dashboard	An existing board, with every widget on it	A board
Presentation	A presentation built in the system, with every slide	A presentation
Saved table view	Its filters and sorting, over today's data	A view
CVE vulnerability register	A severity summary and the open vulnerabilities	—
Patch suggestions	Systems ranked by urgency	—
Capacity plan	The annual document — drivers, resources, capacity figures, trends and recommendations	—

Not every table can be scheduled: it needs a row source the server can read for itself at three in the morning. The saved-view picker hides a view whose table is not supported — and says how many views it hid, rather than simply showing fewer.

The data period

A period is asked for only on a dashboard and on a presentation. Every other subject is a point-in-time answer — "what is open now", "what is urgent now" — and a period control there would be a control that does nothing.

The period is stored as a rule rather than as a date range: "the one that ended" or "the current one (partial)", resolved afresh on every run. It appears on the document's cover slide, and every item carries a line saying how the period applies to it.

What is behind the numbers depends on the subject, and this is the practical difference between the two:

• A dashboard is photographed afresh on every run, so its numbers are true as of the moment it was sent. An item that is not period-scoped — inventory, a register — shows the state on the day of production, and the document says so beside it.
• A presentation is sent with the numbers produced when a person last saved it. They are not recomputed at production time, in any item — not even one that is not period-scoped. The document says so: a period-scoped item carries a line stating that its numbers were computed at the last save and were not recomputed for the period, and an appendix at the end of the deck states explicitly which date the data is true as of.

When

Cadence: daily · weekly · monthly · quarterly, with a day and a time from pickers. There is no cron expression — "every Monday at 07:00" out of two lists is what someone scheduling a management report needs, and there is far less in it to get wrong.

• Quarterly means January, April, July and October.
• The time is the server's clock. The actual run may be a few minutes late, because the checker works in cycles.

To whom

Recipient groups, individual recipients, or a mix, and each recipient carries the role To or Cc. The Who will actually receive it section gathers the final list and states explicitly when nobody is in "To" — such a report fails on every run.

A standing distribution list is built once in Recipient groups.

Format

HTML rides in the message body and is read without opening a file. Every other format is sent as an attachment, and the text you wrote becomes the covering message. The list is built from what the server can actually produce, and an unavailable format is shown with its reason.

The test before enabling

A new report is saved disabled, deliberately. The order is write, send a test, and only then enable.

• Send now really produces and really sends, and marks the send as a test in the log. It does not count as a scheduled run and does not move the next run time. There is no dry run: a feature whose entire output is an email is only proven when an email arrives.
• A dashboard report also has Preview — a photograph of the real board, right now, to look at, with nothing sent.

Enabling a report written weeks ago recomputes the next run time instead of firing immediately against a time long past.

How it behaves over time

Success advances the schedule. That is what takes the report out of every later scan, which is why an occurrence is sent at most once.

Failure does not advance it. The time stays where it is and the next cycle tries again. When the attempt budget runs out the schedule advances anyway — a dead mail server costs a few attempts per occurrence rather than freezing the schedule forever.

Catch-up fires once. A report whose time passed while the server was down is sent once and advanced to the next occurrence after now. Walking forward occurrence by occurrence would put three identical emails in an inbox at once.

The board that is photographed

A dashboard report is produced by photographing the real board in a browser running on the server — not by recomputing the same groupings on the server side, which would give the product two implementations of one aggregation.

The capture waits until the board has finished loading rather than for a fixed interval. If the time limit passes the board is photographed anyway, and the document says some widgets may be empty.

Delivery log and deletion

Every run is recorded — real or test — with the time, the outcome and the detail.

Deleting a report is immediate and also removes its delivery history. To stop the sending without losing the definition, disable the report instead.