Skip to main content

Running Aggregates

Running aggregates compute a cumulative or rolling value across the rows of a table or chart, in sort order. Unlike standard aggregates (which collapse all rows into a single value), running aggregates keep each row but add a column showing how the value accumulates.

Running aggregates are used in output components — they are configured in the Output Designer, not in the blueprint.

Available running aggregate types​

FunctionDescriptionCommon use
running_sumCumulative sum of the field's values in sort orderCumulative spend, cumulative progress
running_avgCumulative average up to and including each rowRolling average trend, moving baseline
running_countCumulative count of non-null values in sort orderCumulative actions closed, cumulative risks opened
running_minMinimum value seen so far in sort orderRunning floor / best-case value
running_maxMaximum value seen so far in sort orderRunning peak / worst-case value

Where running aggregates can be used​

Running aggregates are available in:

Component typeUse case
Table — as an additional columnShow cumulative spend alongside period spend in each row
Line chart — as an additional seriesOverlay a cumulative trend line on a period-by-period bar
Bar chart — as a secondary seriesAdd a running total line to a grouped bar chart
Calculated field in outputReference the running aggregate in an expression for a KPI or annotation

Running aggregates are not available in:

  • KPI card value fields (which collapse to a single value by definition)
  • Gauge and indicator components
  • RAG grid components

Configuring a running aggregate in a table​

Step 1 — Open the table component in Output Designer​

  1. Open the blueprint → Output Designer → select the output template.
  2. Click the Table component on the canvas.
  3. Open the Data panel on the right.

Step 2 — Add a running aggregate column​

  1. In the Columns list, click + Add column.
  2. In the column type selector, choose Running aggregate.
  3. Configure:
SettingDescription
Header labelColumn header text (e.g. "Cumulative Spend")
Source fieldThe numeric field to aggregate (e.g. Period Cost)
Aggregate typerunning_sum, running_avg, running_count, running_min, or running_max
Sort fieldThe field that defines the accumulation order (e.g. Period Date, Week, Row number)
Sort directionAscending (default) or Descending
Reset on groupIf grouping is active, reset the running total at each group boundary (see below)
FormatNumber format — same options as the source field's format panel
  1. Click Apply.

The column appears in the table preview with live values.

Configuring a running aggregate series in a chart​

Step 1 — Open a line or bar chart component​

  1. Click the chart component on the canvas.
  2. Open the Series panel.

Step 2 — Add the running aggregate series​

  1. Click + Add series.
  2. Set Series type to Line (for a bar chart, this creates a combo bar+line chart).
  3. Set Value source to Running aggregate.
  4. Configure:
SettingDescription
Source fieldThe numeric field to aggregate
Aggregate typerunning_sum, running_avg, running_count, running_min, or running_max
Sort axisThe dimension axis the chart is sorted by (typically the X-axis date or period field)
Y-axisPrimary or secondary axis (use secondary to keep scale readable when the running total is much larger than period values)
  1. Style the series: colour, line style (solid, dashed), line width, and show/hide data point markers.

Sort order dependency​

Running aggregates are order-dependent — the same data produces different running values depending on the sort order.

Example: running_sum of Period Cost

PeriodPeriod Costrunning_sum (asc date)running_sum (desc date)
Jan100100600
Feb150250500
Mar200450350
Apr150600150

Always set the Sort field explicitly. If the sort field is ambiguous (e.g. rows have the same date), the running aggregate result is non-deterministic.

caution

If your table or chart does not have a stable sort order, running aggregate values will be inconsistent. Set an explicit sort field on the component — and if the component allows multi-level sort, add a tie-breaker (e.g. row ID) as the secondary sort.

Interaction with grouping​

When a table or chart has grouping enabled (e.g. grouped by Discipline or Month), running aggregates can behave in two ways depending on the Reset on group setting:

Reset on groupBehaviour
On (default)The running aggregate resets to zero at the start of each group. Produces a per-group running total.
OffThe running aggregate continues across groups — producing a workspace-wide running total that ignores group boundaries.

Example — Cost by Discipline (grouped by Discipline, Reset on group: On):

DisciplinePeriod Costrunning_sum
Civil100100
Civil200300
Structural150150 ← resets at group change
Structural100250

Same data (Reset on group: Off):

DisciplinePeriod Costrunning_sum
Civil100100
Civil200300
Structural150450 ← continues from previous group
Structural100550

Filter interaction​

Running aggregates respect the component's active filters. If a filter excludes certain rows, those rows are not included in the accumulation. The running aggregate only runs across the visible (unfiltered) rows.

Example: If a table filters Period = "2026" and the data includes 2025 rows, the running total starts from the first 2026 row — it does not include 2025 values.

This is the expected and correct behaviour. If you need a cumulative total that includes prior periods not visible in the current filter, use an expression-based calculated field referencing a separate unfiltered data source.

Running average vs. simple average​

ConceptDescription
running_avgAverage of all values seen so far in sort order. Changes with each row.
Standard Average aggregateSingle value: average of all rows in the data source. Same for every row.

Use running_avg when you want to show how the average improves or deteriorates over time. Use standard Average in a KPI card or table footer when you want a single summary value.

Performance considerations​

Running aggregates add a computation step to output rendering. For tables with:

  • < 500 rows: No perceptible performance impact.
  • 500–2000 rows: Minor rendering delay (< 1 second).
  • > 2000 rows: Consider whether running aggregates are the right tool — at this scale, pre-aggregated data in a blueprint computed field may render faster.