A report is a table of records. Where a widget answers how many, a report answers which ones.
When you want one
Somebody needs the list. Every overdue invoice, every deal closing this month, every employee whose review is due.
Somebody needs it outside the platform. An accountant, an auditor, a board pack.
The next action is per record. A number tells you there is a problem; a report tells you which eleven things to do about it.
Building one
You pick the record type, which columns to show, how to filter, and how to sort and group.
The columns available come from the platform's own catalog, which means your custom fields are there without anybody adding support for them.
Names, not identifiers
Worth stating because it is a genuine differentiator and an easy thing to get wrong.
Where a column points at another record, the report shows the name rather than the internal identifier. An owner column shows a person's name. A company column shows the company.
This holds in exports too. A CSV that resolves to names in the browser and identifiers in the file is a familiar and infuriating failure, and it is specifically handled here: the export goes through the same resolution the screen does.
Where something genuinely cannot be resolved, it is shown as a dash rather than as a raw identifier. An identifier on screen is always a defect, never information.
Grouping
Rows can be grouped, with each group carrying its own subtotal.
Useful for the common shape: everything, arranged by owner or by region, with a figure per group and a total at the bottom. It is the report equivalent of a pivot and it keeps the underlying rows, which a pivot does not.
Filters
The same distinction as everywhere else in Analytics: filters narrow which records, the period narrows when.
For a report the filters carry most of the weight, since a report's value is precision. A report of all invoices is a table; a report of invoices over thirty days overdue, above a threshold, sorted by age, is a morning's work laid out in order.
Exporting
Spreadsheet and CSV.
Check the first export. Column order, resolved names, the right filter applied. It takes thirty seconds and it is the difference between a report somebody trusts and one that gets quietly rebuilt by hand.
Columns
The columns available come from the record type's own fields, including anything your organisation added.
Two habits. Put the identifying column first, so a reader knows what each row is before they read anything about it. And put the column you sorted by second, since that is the one they are scanning.
Scheduling
Reports deliver on a timetable exactly as boards do, with the same cadences, recipients, formats and periods.
A scheduled report is frequently the right answer where a scheduled board is not, because a table survives being read in an email in a way a dashboard does not.
Sorting and grouping
Both change what a report is for, and it is worth choosing rather than accepting the default.
Sorting decides what gets attention. The top ten rows are read; the rest are scrolled. Sort by whatever should be dealt with first, not by name or by date created.
Grouping turns a list into a comparison. The same rows grouped by owner answer a different question from the same rows grouped by region, and the subtotals are where the answer lives.
Reports on an HQ
Each part of the platform carries its own reporting surface, showing that area's measures without anybody assembling them.
That is where to look first. A question about sales usually has an answer already built in Sales, and building a report from scratch to answer it is work nobody needed to do.
Reports are live
A report re-runs when opened. It is a definition, not a saved result.
That is worth knowing in both directions. Opening the same report next week gives next week's answer, which is what you want. And a report you send as a file is a snapshot that starts ageing immediately, which is why scheduled delivery exists rather than people forwarding yesterday's spreadsheet.
Writing one somebody else can use
Filter to what is needed and nothing more. A report of everything, to be filtered by the reader, is a table rather than a report.
Order by what they will act on. Most overdue first, largest first, soonest first.
Cut the columns. Six that matter beats twenty that might. Every extra column costs the reader attention and gains almost nothing.
Name it for the job. "Overdue invoices over thirty days" beats "Invoice report".
Reports and widgets answer different questions
Worth being explicit, because people reach for the wrong one regularly.
A widget aggregates. It tells you how many, how much, which way it is going. It is for noticing.
A report enumerates. It tells you which records, with their details. It is for acting.
The tell is what somebody does next. If the next step is a decision, they want a widget. If the next step is working through a list, they want a report, and giving them a chart means they will ask for the list anyway.
Who can see what
A report shows the records the reader is allowed to see, so two colleagues opening the same report can legitimately get different row counts.
That matters most on export and on scheduled delivery: a report scheduled by somebody with wide access delivers their view to every recipient, including people who could not see those rows themselves.
Worth a thought before scheduling anything to a wide list.
What a report is not
It is not a data export. Taking your data out wholesale is a different surface with different guarantees.
It is not a backup. A CSV in somebody's downloads folder is a copy that ages instantly and is nobody's responsibility.
It is not a substitute for the working screen. A list of overdue invoices tells you what to chase; the chasing happens in Finance, where the record can actually be changed.
Did this answer your question?
No, ask a person