Exporting and Scheduling Reports

Export formats#

Any chart can be exported. The available formats come from two places:

PDF, PNG, and JPEG are always available because they do not depend on the chart type — Infohub renders the chart in a headless browser and captures the result. That has a useful consequence: an exported image looks exactly like the chart in the browser, because it is the same rendering.

Data formats are per chart type. Tables support CSV, which is the one that matters most in practice.

Images or data?#

Choose by what the recipient will do.

Send an image or PDF when the recipient will read it. A shift report, a management pack, a compliance record. It preserves layout, colour, and limit indicators, and it cannot be accidentally altered.

Send CSV when the recipient will work with it. Combining with data Infohub does not hold, doing their own analysis, importing into another system. An image forces them to retype numbers, which they will do, with errors.

A great deal of frustration comes from sending the wrong one. If someone keeps asking for "the numbers" after receiving a PDF, they wanted CSV.

Report servers and templates#

Scheduled distribution is handled by a report server — one of the service objects hosted by Bootstrap on a Platform, alongside the Data Engine and Flow Server.

A report server template defines what gets produced and sent: which dashboards and reports are included, and the schedule. Dashboards and reports are attached to the template, and dashboard loops are configured here too.

Because a report server is a deployable service object, it follows the same rules as everything else: it must be placed on a Platform, and it must be deployed before it does anything. A configured-but-undeployed report server is a common cause of "the reports stopped" — see Deploying Configuration.

Designing a report for paper#

A dashboard designed for a screen frequently prints badly, and the fixes are straightforward once you know to make them.

Fix the width. A table with more columns than fit a page is unusable on paper regardless of how it looks on screen. Count the columns against the output width. Consider the portrait table orientation for measure-heavy content.

Do not rely on interaction. No tooltips, no hovering, no drill-down. Everything the reader needs must be on the page.

Make colour survive monochrome printing. Many recipients print in black and white, where red and green become the same grey. Pair colour with a value or a word — a Fail label alongside the red — so the message survives. See Format Strings for the three-section pattern that produces those words.

State the period and the run time on the page. A printed report with no date is worthless a week later, and someone will find one in a drawer and act on it.

Include the units. They come from the measures, so this is mostly a matter of having set them properly.

Timing a scheduled report#

The most common scheduled-report failure is not an Infohub problem at all: the report runs before the data it reports on exists.

A daily report scheduled for 06:00 covering the previous day needs every measure in it to have been calculated for that day. If a source delivers late, or a long aggregation chain has not finished, the report goes out with gaps — and it goes out looking authoritative.

Practical defences:

• Schedule with a margin. If the data is normally complete by 05:30, schedule at 06:30, not 05:35.
• Understand the slowest input. A monthly report depending on a manually entered figure cannot run before the person enters it. That is an organisational deadline, not a technical one.
• Check the first few runs against the dashboard at the same time, and confirm they agree.
• Consider reporting on complete periods only. A daily report covering yesterday is safer than one covering today so far.

Distribution#

Scheduled output is distributed through Infohub's notification channels — email being the usual one, with Teams, Slack, and a file drop also available.

A file drop is worth knowing about: writing the output to a network share rather than emailing it. That suits reports that are large, that go to a shared location by convention, or that another system picks up. Note that the file drop runs as the Bootstrap service account, so that account needs write access to the share.

See Notification Services.

Who receives what#

Two habits prevent the most common complaints.

Keep distribution lists current. A report emailed to a team is a list that decays — people leave, roles change, and eventually nobody who receives it is responsible for it. Review the lists periodically. Where possible, send to a role-based address rather than to individuals.

Send less. A daily report that nobody reads trains its recipients to filter Infohub's mail, and the monthly one they should read goes to the same folder. If a report has no audience, stop sending it.

Exporting from the web client#

Users can export a chart they are looking at directly, which covers the ad-hoc case without configuration. It is worth telling users this exists — it prevents a stream of requests for one-off reports that they could produce themselves in two clicks.

Diagnosing#

See also#

• Tables and Portrait Tables
• Dashboards and Navigation
• Notification Services
• Running the Data Engine