In Tableau, when does a table calculation such as RUNNING_SUM actually compute?

## Three places a calculation can run Tableau evaluates calculations at three different moments, and knowing which one you are in explains most surprising numbers: - **Row-level** (`[Sales] - [Cost]`) — in the data source, per underlying row. - **Aggregate and level of detail** (`SUM([Sales])`, `{FIXED [Region] : SUM([Sales])}`) — in the query, at the view's grain or the grain the LOD declares. - **Table calculation** (`RUNNING_SUM`, `WINDOW_SUM`, `INDEX`, `RANK`, `LOOKUP`) — in Tableau, after the query has returned, over the aggregated result. A table calculation is therefore the last thing to happen. The data source never sees it, and it can never reach back into detail the query did not return. ## What it operates on Once the query returns, Tableau holds a small table of aggregated values — one row per mark. That table is what a table calculation reads. This is why every table calculation function takes an aggregate as its argument: `RUNNING_SUM(SUM([Sales]))` is well formed, `RUNNING_SUM([Sales])` is not, because there is no bare `[Sales]` left at this point. ``` RUNNING_SUM(SUM([Sales])) -- cumulative to the current mark WINDOW_SUM(SUM([Sales]), -2, 0) -- trailing three marks, inclusive LOOKUP(SUM([Sales]), -1) -- the previous mark's value INDEX() -- position of the mark within its partition ``` ## Addressing and partitioning Every dimension in the view is either **addressing** or **partitioning** for a given table calculation. Addressing dimensions define the direction the calculation moves along; partitioning dimensions carve the table into independent groups, and the calculation restarts in each one. In the interface this is the Compute Using setting — Table, Pane, Cell, or a specific list of dimensions. A running total of monthly sales in a view of Year and Month, addressed by Month only, restarts every January because Year partitions it. Addressed by both Year and Month, it runs continuously across the whole table. The formula is identical in both cases; only the addressing differs. Setting Compute Using to specific dimensions rather than the positional defaults (Table across, Pane down) is what keeps a calculation correct after someone reorders the shelves. ## The invisible-data problem Because the calculation runs on what came back, anything filtered out is gone. Filter a view to the last quarter and `RUNNING_SUM(SUM([Sales]))` starts from zero at the beginning of that quarter — it cannot include January, because January never arrived. Similarly, a table calculation cannot compute a distinct count across data outside the view, or reference a dimension that is not in the view at all: it can only address dimensions that are present, including those parked on Detail. When you need a number computed over data the view does not show, that is a level of detail expression's job, not a table calculation's. `{FIXED [Customer ID] : SUM([Sales])}` is answered by the data source over the whole table; `WINDOW_SUM` can only add up what is on screen. ## Filters on table calculations run last of all There is one useful exception to "filtering changes the calculation". A filter placed on a *table calculation* is applied after the table calculations are computed, so it hides marks without recomputing anything. That is the standard way to show only the last six months of a running total while keeping the total correct: build the running sum over the full period, then filter on a table calculation such as `LAST() <= 5` to trim the display. A plain dimension filter on the date would instead remove the rows and reset the running total. ## Symptoms to recognise - A percent-of-total that always shows 100% — the calculation is partitioned by the very dimension it should be spanning. - A running total that resets unexpectedly — an extra dimension in the view has become a partition. - A number that changes when someone swaps Rows and Columns — the calculation is using a positional Compute Using rather than named dimensions. - A cumulative figure that starts at the wrong opening balance — a dimension filter removed earlier periods before the calculation ran. ## What interviewers listen for They want you to place table calculations last in the pipeline and to explain the practical consequence: they see only what the view returned, and their result depends on the table's shape through addressing and partitioning. Naming the late-filter trick, and knowing when to reach for a level of detail expression instead, is what separates a confident answer from a memorised one.