Subcharts — a chart inside every cell
A pivot cell normally holds one number. A subchart replaces that number with a small view of a whole field — a doughnut, a bar chart, a nested table or a plain list — drawn separately inside every cell.
Instead of reading "Mitch Davis has 12 Stories" you see how those 12 split across statuses, for every person and every issue type at once.
First decide whether you need one
A subchart answers a question of the form "and what is that made of?". Before reaching for it, check which of these you are actually asking:
What you need | Use |
|---|---|
One number per intersection — how many, how long, how much | A plain measure in Cell content. Faster to read and to compare down a column. |
To compare a third field across rows — is Mitch's To Do share bigger than Cassi's? | A second Columns grouping field. Numbers in aligned columns compare far better than shapes in separate cells. |
The composition inside each intersection, where each cell is read on its own | Subchart. This is what it is for. |
The test: if your sentence about the report contains the word "of" — the split of statuses, the breakdown of time — a subchart fits. If it contains "compare", add a column instead.
Then pick the field to nest
A cell is small. The nested field has to fit in it, so the number of distinct values matters more than anything else.
Good: Status, Priority, Issue Type, Resolution, Component — a handful of values, stable across rows.
Risky: Sprint, Fix Version, Label — fine on a narrow scope, unreadable on a wide one.
Bad: Assignee across a large instance, Summary, any date that is not bucketed. Forty slices in a 100 px doughnut is decoration, not information.
If the field has many values but you only care about some of them, nest it anyway and cut it down with Filter cell content — see below.
Add it: the tab most people miss
Open Set chart and fields and click Add cell content. The dialog has two tabs:
Tab | What it contains |
|---|---|
Measure | Numbers — Count of Issues, sums, averages, minimums, maximums, time in status. |
Field values / Subchart / Subtable | Jira fields — Status, Priority, Sprint, your custom fields. This is the tab you need. |
Searching the Measure tab for "Status" returns only measures such as Sum of Time in Status. The plain Status field is on the Field values / Subchart / Subtable tab. This is the single most common reason people conclude the feature does not exist.
Now choose how it renders
The new field arrives in Cell content as a card. Expand it with the chevron on its right — that card is where every subchart setting lives. The one that decides everything is Subchart.
The choice follows the same logic as picking a visualisation for the report itself — shape versus number — with one extra constraint.
Subchart | Choose it when | Needs a measure? |
|---|---|---|
List (vertical / horizontal) | You want to know which values are in there, not how many. The lightest option and the safest default. | No |
Pivot table (vertical / horizontal) | You need the exact number per nested value and expect people to read the figures. | Yes |
Doughnut or Pie | The proportions matter and there are roughly 2–6 values. Above that the slices stop being distinguishable. | Yes |
Bar | More values than a pie can carry, or values with a natural order — dates, priorities, sizes. | Yes |
Start with List (vertical). It needs nothing else, renders instantly, and tells you whether the field you nested was a sensible choice before you invest in a chart.
Give a chart something to measure
A list shows values on its own. A chart cannot — it needs to know how big each slice is. Pick a chart without one and the card says so:
To use this chart, add a measure to the subchart content of this item, or switch to "List (vertical)" / "List (horizontal)" to display values without a measure.
Click Add subchart content on the same card and pick the measure — Count of Issues in most cases, a sum when you are splitting an amount rather than a count. Every cell then draws.
Shape what goes inside
Setting | What it does, and when you need it |
|---|---|
Filter cell content | Filters only what appears inside the cells; the surrounding table keeps counting everything. This is how you nest a wide field sensibly — show only the unfinished statuses in the doughnuts while the rows still total all work. |
Bucket by | Groups the nested values the way it does for rows. Nesting a date without bucketing it is the classic way to produce an unreadable cell. |
Titles | In main table header keeps cells clean and is right for a single nested field. In each cell is only worth it when several nested fields would otherwise be indistinguishable. Hidden when the caption already says it. |
Subchart additional content | Holds the measure a chart needs — and can hold another field, nesting one level deeper. |
Two levels of nesting means every cell renders a chart containing charts. It is supported, and it is slow and hard to read. Before going there, ask whether that second level is really a column grouping in disguise.
Make it readable
Defaults are generous with space, so a first attempt usually shows two or three rows and a lot of scrolling. Three fixes, in the order they matter:
Style → Nested chart width. The default is built for one wide chart per row. Around 100 px fits a whole table of doughnuts on screen; a Pivot table subchart needs more like 170 px, because it has to fit a value and a number side by side.
Remove the plain measure from Cell content if you left one there. Otherwise every cell carries a number and a chart, doubling the width and halving the legibility.
Hide the totals. Set Totals row and Totals column to Hidden in Style — a totals column full of doughnuts competes with the data and answers nothing.
Cost
A grid of forty charts takes noticeably longer to render than a grid of forty numbers, and the cost grows with rows × columns × nested values. Keep the scope tight, and prefer a list subchart when you do not actually need the chart.