BIChart Logo
BIChart

Understanding RUNNING_SUM in Tableau: A Comprehensive Guide

Tableau

Summary of RUNNING_SUM in Tableau

RUNNING_SUM is Tableau’s table calculation designed for cumulative totals. It addresses a common reporting challenge: tracking how a metric accumulates over time or across a sorted category list. Instead of presenting each row or mark as an isolated value, RUNNING_SUM adds the current value to all prior values in the specified table calculation direction. This feature is particularly useful for metrics such as running revenue, cumulative orders, progressive percentages, and any other metric that requires accumulation rather than a simple aggregate.

TABLEAU RUNNING_SUM

Problem Definition: The Need for Cumulative Metrics

Many dashboards require a metric that accumulates as you progress through a sequence. Common questions include:

  • What is the total sales to date by month?
  • How much revenue has each product contributed as we move down a ranked list?
  • What is the cumulative order count across a time series?
  • How does a metric build toward a final total?

A standard sum provides the value for the current mark only, while a running total reflects the value accumulated so far. This distinction is crucial when the business question focuses on progress, buildup, or trends rather than just the final total.

Key Concept: How RUNNING_SUM Works

RUNNING_SUM operates by taking the current value and adding it to all previous values in the specified table calculation order. The key idea is not merely summing data but summing it in sequence. This sequence is influenced by the layout of the visualization and the table calculation settings. Therefore, the calculation relies on two factors:

  • The values being aggregated
  • The order in which Tableau processes the marks

If the order changes, the running total will also change.

Data Example: Monthly Sales Table

Consider the following simple sales table:

OrderMonth Sales
Jan 100
Feb 150
Mar 200
Apr 50

If the question is “What are monthly sales?” the answer is simply the Sales column. However, if the question is “What is sales to date?” we need a cumulative result. The running total would appear as follows:

OrderMonth Sales Running Sales
Jan 100 100
Feb 150 250
Mar 200 450
Apr 50 500

In this example, the February value includes both January and February, while the March value includes January, February, and March. This illustrates the core analytical behavior of RUNNING_SUM.

Tool Implementation: Using RUNNING_SUM in Tableau

What RUNNING_SUM Is in Tableau

In Tableau, RUNNING_SUM is classified as a table calculation. It computes a cumulative total across the current partition. The syntax for using RUNNING_SUM is as follows:

RUNNING_SUM(expression)

For example:

RUNNING_SUM(SUM([Sales]))

This means that Tableau first aggregates Sales at the level of the view and then accumulates those aggregated values across the specified table calculation direction. This detail is significant because RUNNING_SUM does not calculate directly from raw rows like a database sum would; it operates on the results already produced in the visualization.

Applied Example: Cumulative Sales Calculation

Suppose the view contains OrderMonth on the columns and Sales on the rows. The calculated field would be:

RUNNING_SUM(SUM([Sales]))

Tableau would then return a cumulative series as follows:

OrderMonth SUM(Sales) RUNNING_SUM(SUM(Sales))
Jan 100 100
Feb 150 250
Mar 200 450
Apr 50 500

This cumulative measure is particularly useful for visualizations that aim to show accumulation over time. A line chart with this measure illustrates growth, while a bar chart displays the total building step by step.

Why RUNNING_SUM Exists: The Need for Cumulative Measures

Default aggregation provides the value for each mark. For instance, if the view shows Month, Tableau computes:

SUM([Sales])

by month, yielding one value per month. However, it does not automatically account for prior months. RUNNING_SUM exists to override this default mark-by-mark behavior and transform a standard aggregate into a cumulative measure. This feature is essential for trend analysis, progress tracking, and cumulative reporting.

Important Behavioral Details of RUNNING_SUM

1. RUNNING_SUM is a Table Calculation

Understanding that RUNNING_SUM is a table calculation is crucial. Table calculations operate after Tableau builds the visualization, meaning that RUNNING_SUM depends on the structure of the view. If you rearrange fields, change sorting, or modify partitioning, the result can change.

2. Sorting Affects the Result

The cumulative total follows the order of the table calculation. If months are sorted from January to April, the result is accurate for time. However, if the view is sorted by Sales in descending order, the running total will follow that order instead. While this may be useful for ranked accumulation, it no longer represents a time series.

3. Filters Can Change What Gets Accumulated

Since RUNNING_SUM operates on the displayed marks, filters can alter the set of values being accumulated. For example, if a filter removes February, then March will no longer include February in the running total. This behavior is expected for table calculations but may surprise teams transitioning from SQL-based cumulative logic.

4. Partitioning Controls the Reset Point

RUNNING_SUM resets for each partition. For instance, if the view includes Region and Month, the running total can restart for each region based on how the table calculation is addressed. This allows for one cumulative series per region instead of a single global cumulative series.

5. It Follows the View, Not Just the Data Source

Many implementation issues arise from this principle. Two dashboards can utilize the same field and yield different running totals if the visual layout differs. The expression is not solely about data; it also considers how the view is arranged.

6. Totals and Subtotals Require Attention

Table totals and subtotals do not always behave like ordinary marks with table calculations. A running total in the body of the view may appear correct, while totals display a different result or necessitate special handling. This is a common edge case in reporting views.

Real Usage Patterns for RUNNING_SUM

Common applications of RUNNING_SUM include:

  • Cumulative sales by month
  • Cumulative orders by day
  • Running profit and loss
  • Progressive delivery volume
  • Cumulative customer count
  • Growth tracking in funnel reports
  • Cumulative percentages when combined with a percent-of-total calculation

RUNNING_SUM is particularly valuable when the question revolves around pace or buildup. If the business seeks to understand “how much have we accumulated so far,” RUNNING_SUM is typically the appropriate approach. Conversely, if a stable total that does not change with the current table layout is desired, alternative methods, such as fixed aggregation in the data model or a separate calculation layer, may be more suitable.

Practical Interpretation of RUNNING_SUM

Visualize RUNNING_SUM as a cumulative line drawn across the marks in the view. The first mark displays its own value, the second mark shows the sum of the first and second, and the third mark reflects the sum of the first three values. This logic is straightforward once the sequence is visible, but it can become confusing when the view is reordered. The calculation is cumulative, but the sequence is visual.

Conclusion

RUNNING_SUM is one of the most frequently used table calculations in Tableau, as it effectively answers a simple analytical question in a compact manner. To use it effectively, remember three key points:

  • It operates on aggregated view data.
  • It depends on sort order.
  • It resets by partition.

With these principles in mind, applying RUNNING_SUM in dashboards and migration work becomes a straightforward task.

Ready to migrate? Start today.

Join the growing number of companies that have simplified their Tableau to Fabric migration with BIChart.

Ryan Goodman

Ryan Goodman

Ryan Goodman has been in the business of data and analytics for 20 years as a practitioner, executive, and technology entrepreneur. Ryan recently returned to technology after 4 years working in small business lending as VP of Analytics and BI. There he implanted an analytics strategy and competency center for modern data stack, data sciences and governance. From his recent experiences as a customer and now working full time as a fractional CDO / analytics leader, Ryan joined BIChart as CMO.