Delivering reports: scheduling, distribution and self-service

Why this matters

A report is only useful if it reaches the right people, at the right time, with the right data, and only them. Delivery is where good analysis often falls down: a weekly report nobody opens, a dashboard that shows last week's data, a file of customer details forwarded far beyond its intended readers, or twenty versions of a report in circulation with different numbers.

The exam's reporting objective covers appropriate delivery methods. This lesson covers the reporting cadences, scheduled delivery and alerts, self-service reporting, access control for reports, and managing reports over their life.

The lesson

Ad hoc, recurring and real-time reporting

Reports are delivered on different rhythms, and the rhythm should match how the information is used.

Ad hoc reports answer a one-off question: the effect of last month's promotion, or the customers affected by a pricing error. They are built on request, often quickly, and are not maintained afterwards. Because they are one-off, they need clear dates and definitions, so they are not later mistaken for a regular figure.

Recurring reports are produced on a fixed schedule: daily sales, weekly operations, monthly management accounts, quarterly board packs. Their value is consistency: the same measures, calculated the same way, at the same point each period, so changes are real changes rather than differences in method.

Real-time or near-real-time reporting shows data as it arrives, for operational monitoring: live orders, current queue lengths, system status. It needs fresh data pipelines and is only worth the cost where someone acts within minutes or hours.

The general principle is to match frequency to decision speed. A daily report of a measure that is reviewed monthly adds noise and effort; a monthly report of something that needs daily action arrives too late.

Scheduled delivery, subscriptions and alerts

Recurring reports are usually delivered automatically.

Scheduled delivery runs a report at a set time and sends it, as an email attachment, a link or a file in a shared location, to a distribution list. It removes manual effort and makes timing reliable. Its risk is that scheduled reports keep running long after anyone reads them, and can quietly send stale or broken output if the underlying data failed to refresh.

Subscriptions let users choose to receive a report or dashboard snapshot on their own schedule, rather than being on a list someone else maintains.

Data-driven alerts send a notification only when a condition is met: sales below a threshold, an error rate above a limit, a KPI moving outside its expected range. Alerts suit exceptions better than regular reports do, because they demand attention only when something needs it. Their risk is alert fatigue: too many alerts, or alerts on normal noise, teach people to ignore them. Thresholds should be set with the data's normal variation in mind.

Every scheduled output should show when its data was last refreshed, so a recipient can tell whether they are reading today's numbers.

Self-service reporting and its risks

Self-service reporting lets business users build or customise their own reports in a BI tool, using data prepared for them. It reduces the queue of requests to a central team and lets people answer their own questions quickly.

It carries risks that must be managed:

• Inconsistent definitions: users calculate the same measure differently, and their reports disagree.
• Report sprawl: hundreds of similar reports, many unused, and uncertainty about which is authoritative.
• Errors: joins, filters and calculations built by people without analytical training, published without review.
• Data exposure: sensitive data included in reports and shared too widely.

The common safeguards are certified data sets with governed measures that self-service reports must build on, clear labelling of certified against personal reports, training, and review before a self-service report is shared widely or used for decisions.

Access: who may see which report

Reports often contain sensitive data: salaries, customer details, commercial results, health information. Controlling access is part of delivering them.

Access can be controlled at several levels:

• Report or dashboard level: who can open it at all.
• Row-level security: users see only the rows they are entitled to, such as a regional manager seeing only their region, from the same report.
• Column or field level: sensitive fields hidden or masked for some users.
• Export and sharing controls: whether users can download data or share the report onward.

The principle is least privilege: people see what their role requires. Email distribution deserves particular care, because an attachment can be forwarded without any control, whereas a link to a secured report checks access each time it is opened. For sensitive data, links to secured reports are preferable to attachments.

Report versioning and retiring old reports

Reports change over time: a measure is redefined, a new breakdown is added, a data source is replaced. Managing those changes keeps reports trustworthy.

Versioning records what changed and when: a change log on the report, or version control for its definition and code. When a definition changes, reports should say so, because a figure that jumps between two periods may reflect the new definition, not the business.

Changes should be communicated to users before they take effect, and significant changes should ideally be tested in a copy before replacing the live report.

Retiring reports is as important as creating them. Unused reports consume maintenance, confuse users searching for the right one, and may keep sending sensitive data to people who no longer need it. Usage statistics show which reports are opened; those nobody uses can be confirmed with their owners and removed, with their final version archived if it may be needed as a record.