Chart data shaping — getting your report into chart shape
In the last lesson the data was already chart-ready. Real data almost never is. This lesson is the part customers get stuck on: taking a report full of raw rows and reshaping it until every category is one clean row with its numbers in place. Once you can see the shape a chart needs, the fixes — aggregating, hiding, pivoting — are quick.
By the end of this lesson
- Recognize when a report is not yet chart-shaped — and the duplicate-argument tell that proves it
- Collapse a report to one row per argument with multiple value series, and keep filter-only fields out of the grain
- Transpose tall data with Simple Pivot, flip series orientation, and know the path to year-over-year comparisons
You'll need
- Your first chart — the argument / value-series model and the visualization builder
- Comfort with aggregate formulas (count, sum, average) — see Report formulas. Aggregating is the main tool in this lesson
Background
One rule carries this whole lesson, and it's the one from the basics: a chart wants one row per argument, with the value already aggregated. Everything here is a technique for forcing real data into that shape.
The mental move is to decide, deliberately, what your category is — the argument — and then treat every other field as one of two things:
- A value series — a number you want plotted for each category. These you aggregate (count, sum, average) so there's one number per category.
- Everything else — fields that aren't the category and aren't a number you're plotting. These have to be removed from the grain: aggregated away, or hidden, or they'll split your rows.
That second group is where charts go wrong. Every visible column is part of a row's identity. Leave an extra one turned on and a single category fractures into many rows — one per combination — and the chart faithfully draws all of them. The cardinal sign you've got this problem:
The duplicate-argument tell. If a category shows up on more than one row in your report, your data isn't chart-shaped yet. You want each value of the argument to appear exactly once.
Tall versus wide
Most reshaping is turning a tall report (a category repeated down many rows) into a wide one (each category once, its numbers spread across columns). Here's the move, using a finance example you'll build later in the lesson:
Same numbers, different shape. The wide version has one row per category and each value series in its own column — exactly what the builder reads. Getting from left to right is what the rest of this lesson teaches: sometimes by aggregating, sometimes with a pivot, sometimes by fixing the data at its source.
Wrestling with a specific report's shape and not sure which technique fits? Email [email protected] with the report and what you're trying to chart. Real human, same business day reply.
Do it
-
Use a numeric field as the argument
By default the builder offers only text fields for the argument, because the category is almost always a label. But sometimes it isn't — you want to chart by day-of-week number, or a month number, so the order is numeric and correct.
Try it and you'll get a message: there's no character field, so add one or enable numeric arguments. Do the latter — open Chart Options and check Allow Numeric Argument Fields. The argument dropdown now includes your numeric fields, and you can pick the day-of-week number. (If your data doesn't have a numeric day-of-week column, that's a data-transformation your App Builder can add — covered in Module 3.)
Why the opt-in instead of just showing everything? On a normal report ninety-five percent of arguments are labels, and listing every numeric column would bury the one field you actually want. The checkbox keeps the common case clean and lets you reach for numbers when you genuinely need them.
-
Add multiple value series — and meet the problem
Real charts usually plot more than one number. Take a tickets report with status as the argument, and bring in two measures — response time and time open. Now you have three columns: the argument and two values.
But look at the rows:
OpenandClosedeach appear many times, once per underlying ticket. That's the duplicate-argument tell — the data isn't chart-shaped. A chart built on this would try to draw a bar for every ticket, not one per status. -
Collapse to one row per argument
The fix is aggregation. Just as you counted tickets in the basics lesson, here you put an average on each value field — average response time, average time open. The report collapses to one row per status with two aggregated numbers beside it.
That's chartable data: one row per argument, each value series in its own column. Open the builder, add both value series, and the chart draws cleanly. Which aggregate you choose is a judgment call — count for "how many," sum for totals, average for rates and durations — but the goal is always the same: one number per category.
-
Keep filter fields, but make them non-visible
Here's the trap that breaks more charts than anything else. You want a field available so users can filter or be prompted on it — say
channelorregion— but you don't want it on the chart. If you leave it as a visible column, it becomes part of every row's identity, and your one-row-per-status report fractures into one row per status-and-channel. The chart turns into a tangle.The answer is to keep the field but set it non-visible. A non-visible field still participates in the report — it can carry a criterion or a runtime prompt, so users can still filter by it — but it's not an output column, so it doesn't split your rows. The filter then applies by the chart's argument: pick a channel in the prompt, and every bar re-aggregates to just that channel's data.
The rule of thumb: a field is either something you're charting (visible, aggregated) or something you're filtering by (non-visible). Anything visible that's neither the argument nor a value series is almost certainly fragmenting your rows. Runtime prompts on non-visible fields are covered in Criteria and prompts.
-
Add the series — one at a time, all at once, in order
In the builder's value-series picker you have a choice. Add series one at a time when you have a fixed, known set — response time, then time open — setting each one's color and label as you go. Or pick Select All when your columns are dynamic: if the report grows new columns over time — an
Augustcolumn, then anOctobercolumn as months roll in — Select All keeps adding them automatically, so the chart grows with the data instead of needing a manual edit each month.Order matters for stacked columns. The sequence of your value columns sets the stacking order. If a series is stacking in the wrong place, reset to the grid, drag the columns into the order you want, and rebuild the series — the stack follows the column order.
-
Reshape tall data with Simple Pivot
Sometimes the values you want to plot aren't in separate columns — they're stacked in one. A finance report often arrives this way: a
category, avalue type(Actual,Budget,Forecast), and a singleamount. That's tall: several rows per category, which won't chart.Pivot it. From the Data Prep dropdown, Simple Pivot turns the distinct values of one column into column headers. Pivot
value typeinto columns, withcategoryas the row andamountas the data, and you get the wide shape from Block 1 — one row per category, withActual/Budget/Forecastas their own columns. Now it's a multi-series chart. Best practice: pivot the field with the fewest distinct values into columns, so you don't end up with a hundred columns. The pivot itself is covered in Data Prep tools; this is the moment it pays off. -
Flip the orientation — series in columns vs rows
Once your data is wide, you still get to choose which dimension is the argument and which is the legend, without re-pivoting. In Chart Options, Select Series Type offers Series in columns (the default) and Series in rows.
With the finance pivot, "series in columns" plots
categoryalong the x-axis withActual/Budget/Forecastin the legend. Switch to "series in rows" and it flips:Actual/Budget/Forecastbecome the x-axis and the categories become the legend. Same data, two readings — pick whichever answers the question you're asking.
You have a working connection. Below is what to tighten before real users see it. Skip if you're just testing.
Make it real
Three habits and one genuinely hard case. The hard case — time comparisons — is the most common support question this lesson exists to answer.
Year-over-year and month-over-month: get the columns first
A line or column chart plots the columns that are already in your dataset. So a "this year vs last year" chart needs this year and last year sitting side by side as columns. If your source already exposes them, you're done. If it doesn't, the comparison is the work, and there's a ladder of options from easiest to hardest:
- Shape it at the source (easiest). A database view that flattens the periods into side-by-side columns, mapped into your app. If your data is an Excel upload, lay the periods out as adjacent columns in the sheet. A view becomes a normal app once mapped, so nothing special follows.
- Direct SQL or a stored procedure. If you don't control the source but know SQL, write the query (or call the procedure) to produce the side-by-side columns. See Direct SQL and Stored procedures.
- Linked Documents. When all else fails, combine a this-period report and a last-period report into one dataset. See Linked Documents.
One rule ties the harder paths together: Direct SQL, stored procedures, and Linked Documents don't hand back a strict app — they return a result set or an in-memory combination. To filter it, chart it, and otherwise treat it like any normal report, you load it into Advanced Reports → Virtual App, which presents that result as a virtual dataset you can map columns on and operate on normally. See Virtual App.
And the shortcut worth knowing: the newer visualization types — Calendar and Financials — derive period comparisons straight from raw date data, so for those you don't need any of this. If a time comparison is the whole point, check whether one of those fits before building the columns by hand.
Non-visible fields are your filter toolkit
Past the chart, the visible/non-visible distinction is a habit worth keeping everywhere. Anything a user should be able to filter by — but that you don't want cluttering the output or fragmenting rows — belongs as a non-visible field with a prompt on it. It keeps your reports tight and your charts clean, and it's the same pattern drill-down targets use. Criteria and prompts is the home for this.
Use Select All when columns will grow
If a report's columns expand over time — months, quarters, products added as they launch — build the chart with Select All rather than adding series by hand. The chart then picks up new columns automatically on each run, so a "last twelve months" chart stays current without anyone editing it.
When the app can't shape it, that's a data-source job
If the semantic-layer app simply doesn't give you the columns you need and a pivot won't get you there, stop fighting the report. That's the signal to move up a level: a database view, a Direct SQL query, or a stored procedure, surfaced through a Virtual App. The shaping belongs in the data, not in endless report gymnastics.
If you're stuck
The stumbles particular to multi-series and reshaped data, roughly in the order they bite.
"You have to add a character field" when I try to chart
Your argument is a numeric field and the builder defaults to text-only. Open Chart Options and check Allow Numeric Argument Fields, then pick your numeric column. This is the day-of-week / month-number case from Block 3.
My chart draws a bar for every record, not one per category
The duplicate-argument tell: your category repeats down many rows because the values aren't aggregated yet (or an extra visible column is splitting them). Put an aggregate — count, sum, or average — on each value field so there's one row per category. If it's still fracturing, check for a stray visible column.
I added a field for a filter and the chart fell apart
A visible field becomes part of the row's identity, so adding one multiplies your rows. If you only need the field for filtering or prompting, set it non-visible. It still drives the filter — applied by the chart's argument — without appearing as a column or splitting your rows.
The pivot put the wrong values across the top
Simple Pivot turns the distinct values of the column you choose into headers. If you got a hundred columns, you pivoted the high-cardinality field by mistake — pivot the field with the fewest distinct values instead. And if the orientation is right but reading the wrong way, you don't need to re-pivot: flip Select Series Type between series-in-columns and series-in-rows.
One series dwarfs the others and the axis looks crazy
When value series live on wildly different scales — a count next to a dollar amount in the millions — the small series flattens to nothing against a single axis. Either split them into separate charts, or plot the disparate measure differently (a combo chart, covered later in Module 8). Forcing very different magnitudes onto one axis rarely reads well.
Select All didn't pick up my new column (or grabbed too much)
Select All takes whatever value columns exist at run time. If a new month isn't showing, confirm the column is actually in the report's output (and numeric — only number and currency fields are eligible value series). If it's grabbing columns you didn't want, those columns are in the report; trim the report, or add series individually instead.
None of these match my situation
Email [email protected] with the report, the shape you're after, and a screenshot. Real human, same business day reply.
