Reporting is traditionally a separate activity. You pull data out of the application, load it into a spreadsheet or a business-intelligence tool, build a chart, distribute it, and answer a question that, for all that effort, was often just a group-by and a sum. That detour is fine when the question is genuinely complicated. It's wasteful when the question is ordinary. Grouping and calculations bring the common ninety percent of reporting directly into the viewer, so you're not reporting on your data — you're looking at it.
Adding a grouping to a view is a two-click operation. Pick a property; records group by its value, each group gets a heading, and the table — or whichever viewer you're in — reorganizes itself around those headings. A sales-by-region view goes from a flat thousand-row list to a handful of collapsible regional sections, each with its own rows nested inside. Group headings can be configured to show the group's name together with a row count ("North America — 142"), which gives users a useful summary without having to expand everything.
Multi-level grouping is where the feature really pays off. Group by Region, then within each region by Salesperson, then within each salesperson by Deal stage. Expand and collapse at any level. You get a navigable hierarchy that surfaces patterns the flat view hides. For sales reviews, operational dashboards, or reconciliation work, that hierarchy is often the whole point.
Each group can carry aggregates. The built-in set covers the cases that come up most often: sum, count, count-empty, count-not-empty, and rounded sum for currency values where sub-cent drift from line-level rounding would otherwise distort the total. Aggregates appear alongside group headings and in a grand-total row at the bottom of the table. When a table is grouped by region and sums the deal amounts, the regional subtotals and the overall total are visible at the same time — in the same place users were already looking.
Custom calculations take the feature beyond the built-in aggregates. Using the inline expression language, you can define your own formulas over a group's records — a weighted average, a ratio, a conditional count, a running comparison against a target. The expression has access to the records in the group, so anything that can be expressed as a formula over those rows can appear as a calculation in the view. That's a lot of territory, and it covers most of the aggregations that analysts reach for a spreadsheet to do.
Default grouping saves with the view. A view on Pending orders can land already grouped by Priority and subtotaled by Amount, the way its author intended. Users can override the grouping for their own session if they want a different cut, and the view returns to its defaults next time. That pattern — opinionated defaults, user-adjustable overrides — keeps shared views useful without forcing everyone into exactly the same lens.
Performance is a concern the feature takes seriously. Groupings are applied server-side, not in the browser, which means a view with tens of thousands of underlying rows still opens quickly. Pagination plays nicely with grouping — expanding a large group fetches its rows on demand rather than dumping everything into the page — and calculations are computed at the group level without streaming the entire record set through the client. That matters when you'd like the feature to be used in anger, not just in demos.
Grouping is also the idea behind the kanban view: a kanban board is, conceptually, a grouping by an enumeration property, rendered horizontally instead of vertically. Understanding grouping gives you the model for both — and when you find yourself grouping a table by Stage, switching to kanban is the natural next step, with no reconfiguration required.
When the aggregate answer needs to leave the application — for a board pack, an external partner, a historical archive — the spreadsheet export respects the grouping and the calculations exactly as they appear on screen. The export is a faithful copy of what the user was just looking at, not a raw dump that they then have to re-group. That continuity is what makes grouping inside the viewer a real substitute for external reporting rather than a convenience for casual use.