A pivot answers "this by that". Revenue by owner by quarter. Tickets by priority by team. It is the most useful shape in analytics and the one people previously exported to a spreadsheet for.
What you set
A source, from a searchable list of record types.
A scope, which is the pipeline or area, plus the time window.
Rows and columns, the two dimensions you are crossing.
Measures, the numbers in the cells. More than one is allowed.
Filters, to narrow which records count.
The result is live as you build it, so a wrong dimension is obvious immediately rather than after saving.
Why this replaces a spreadsheet
Almost every organisation has a cross-tab somebody rebuilds monthly by exporting and pivoting by hand.
That export is correct on the day it is made and silently wrong afterwards, it lives on one person's machine, and when they are away nobody can reproduce it.
The pivot here is the same shape and none of those things. It re-runs against live records, it is visible to whoever the board is shared with, and its definition is inspectable rather than being in somebody's head.
Rows and columns are not interchangeable
They render differently and they read differently, and the choice is worth two seconds.
Rows are for the many. The dimension with more values goes down the page, where there is room to scroll.
Columns are for the few. Time periods, a handful of statuses, two or three regions. Anything wide becomes unreadable sideways.
The reliable test: if you would have to scroll horizontally, it belongs in rows.
Totals and subtotals
A pivot carries totals down and across, and they are the part most likely to be read wrongly.
A row total is only meaningful for a flow measure. Summing across periods works for revenue and is nonsense for headcount.
A column total across a dimension is usually fine, since you are adding different owners rather than the same thing at different times.
A grand total is only as honest as the scope. It totals what is in the pivot, not what exists, and a reader will assume otherwise unless the title says so.
Flip it to a chart
The same pivot can render as a cross-tab or as a chart, with a switch.
The table is for reading exact figures and for the person who is going to check one cell. The chart is for the shape, and for anybody who wants the answer rather than the numbers.
Build in the table, because that is where mistakes are visible. Present in whichever suits the audience.
Saving
A pivot saves as a real widget with its own type, so it belongs on a board exactly like a chart built in the studio and re-runs against live data.
That is the difference from the spreadsheet this replaces. A cross-tab exported to a file is correct on the day and wrong afterwards, and nobody knows which.
Drilling a cell
Any cell opens into the records behind it, which is the fastest route from a surprising figure to an explanation.
Worth doing on the outlier every time. A cell that is much higher or lower than its neighbours is either the finding or a data problem, and four seconds of looking tells you which.
Building one that stays useful
Start with the question, not the fields. "Is any owner carrying more than their share" leads to a pivot. "Let me look at deals" leads to twenty minutes of dragging.
Two dimensions, not three. A pivot with too much in it stops being readable, and the second dimension is usually the one to cut.
Watch the empty cells. A cross-tab full of blanks is telling you the two dimensions are not related, which is itself an answer and usually the wrong pivot.
Scope before shape. Narrow the records first. A pivot over everything, then filtered by eye, is how people end up reading the wrong rows.
Scoping first
Narrow the records before shaping the cross-tab, not after.
A pivot built over everything and then read selectively is how people end up quoting a figure that includes a category they would have excluded. The scope is a decision; squinting past rows is not.
Reading one honestly
Three failures are common enough to name.
Reading a total across a snapshot measure. Summing point-in-time values down a column gives a number that means nothing. The measure's class is what prevents the engine doing this; it does not prevent a reader doing it.
Comparing periods of different lengths. A part-month column beside full months always looks like a collapse.
Attributing a difference to the dimension. Two owners with different numbers may have different territories, different tenure, or different luck. A pivot shows a difference; it never shows a cause.
Measures in the cells
More than one measure can sit in a pivot, which is powerful and easy to overdo.
Two is usually the limit. A count beside a value, so you can see both volume and size. Past that, cells get crowded and the eye stops comparing anything.
Mixed classes need care. A flow measure and a snapshot measure in the same cross-tab answer different questions about the same row, and a reader will assume they are comparable.
Filters versus scope
A pivot has both, and the difference matters when somebody else opens it.
The scope is the frame: the pipeline, the window. The filters are the exclusions within it.
Put the durable decision in the scope and the exploratory one in the filters. Somebody inheriting the pivot reads the scope as intent and the filters as a choice they can change.
Exporting one
A pivot exports, and the export carries resolved names rather than internal identifiers, the same as a report.
Worth knowing for the common case where somebody wants the cross-tab in a board pack. The exported file is a snapshot; the pivot on the board stays live.
When to use something else
A funnel if the question is about movement between stages rather than a count within them.
An analysis if there is one measure and one dimension. A pivot with a single column is a bar chart wearing a table.
A report if what you actually want is the underlying records. A pivot answers how many; a report gives you which ones.
Did this answer your question?
No, ask a person