How reports work

Requirements: reading a report needs access to the collection it draws from; building and saving reports needs a role that can create them.

A report is a question you ask of your data, answered from whatever is true right now. You point it at a collection, say what you want to measure, choose how to group the answer, and see it as a chart or a table. Because it runs the moment you open it, a report is never a stale export — it is the current state of your records, counted and arranged the way you asked.

The three choices behind every report

Every report comes down to three decisions. First, the measure — the number you want: how many entries there are (a count), or the sum, average, highest, or lowest of a field, such as total deal value or average booking length. Second, the grouping — how to break that number down: by a field (deals by owner), by a stage (deals by pipeline stage), or by time (bookings by month). Third, the shape — a single figure, a bar or line chart, a pie, or a plain table. Pick those three and you have a report; build a report walks through doing it.

Live, not a snapshot

This is the part that separates a report from a spreadsheet you exported last week. A report holds no frozen copy of your data — it recalculates against live records each time it runs. Close a deal and the revenue figure moves; add a booking and the weekly count ticks up, with nobody rebuilding anything. When you do want to see change over time, a report can compare a period against the one before it, but the baseline is always today's real numbers, not a snapshot from the past.

Narrowing and splitting

Two tools sharpen a report. A filter narrows it to the slice you care about — only this quarter, only over a threshold, only one status — so the number answers the exact question. A second grouping splits each bar or row by another field, letting you see, say, deals by month split by owner. There is a limit worth knowing: a report groups by at most two things at once, which keeps a chart readable rather than letting it collapse under too many cuts.

From a report to a dashboard

A useful report is worth keeping. Save it and it is there to run again; gather several onto a dashboard and you have a single screen that answers the questions you check often — this week's bookings, revenue by stage, new contacts by source. A dashboard can be personal to you or shared with the team, the same way views and layouts are. Alongside ordinary reports, a dashboard can carry pipeline panels — how work flows through your stages, and how long it sits in each — drawn straight from the pipeline itself.

Reports read the model you built

A report is only as good as the records underneath it, because it reads exactly what you modeled. Grouping "by stage" works because you set stages on the collection; grouping "by month" works because a date field holds the date; summing "deal value" works because that field is a number rather than text. This is the quiet payoff of shaping your collections and fields deliberately: clean, typed data turns into clean reports with no extra work. If a report cannot group or total the way you want, the fix is usually in the model, not the report.

Where this connects

To build one, follow build a report. Reports sit alongside views — a view is a saved way to see individual entries, a report is an aggregate answer over many of them — and both rest on the data model. The remaining pages — chart types, filters and date ranges, metrics, and assembling a dashboard — each have their own place in this section.