I can usually spot the moment a Tableau user discovers table calculations, because it's the same moment they discover that the same calculation gives different answers depending on which way they drag a pill. They built a running total, it worked, they swapped two dimensions to "see it differently," and suddenly the running total runs the wrong way — or resets where it shouldn't. They didn't change the formula. They changed the direction the calculation moves through the table, and that direction is the entire secret. Table calculations confuse people because the formula is only half the calc; the other half is which marks it operates over, and in what order.
The whole topic reduces to one distinction: partitioning vs addressing. Get that, and running totals, rank, percent-of-total, and the WINDOW functions all fall into place. Miss it, and you'll keep getting "right formula, wrong number."
What a table calculation actually is
A table calculation runs after Tableau has queried the database and laid the aggregated results out as marks in the view. It doesn't go back to the data — it operates on the table of results already on screen. That's why it can do things SQL aggregates can't express naturally: "running total down this column," "this mark as a percent of the row," "rank within this group," "difference from the previous mark." All of those are computations over the arrangement of marks, which only exists after aggregation. (For the granularity-changing problems that happen before aggregation, you want LOD expressions instead — I'll come back to that.)
Partitioning vs. addressing: the one idea
Because a table calc operates over the marks, you have to tell it how to carve them up. Every dimension in the view is doing one of two jobs:
- Addressing — the dimensions the calculation moves along. These define the direction: "running total along months" means Month is the addressing field. The calc walks through these.
- Partitioning — the dimensions the calculation resets within. These define the groups the calc restarts for: "running total along months, restarting each region" means Region is partitioning. The calc never crosses these boundaries.
Every dimension is either addressing (the calc moves through it) or partitioning (the calc resets at it). That binary choice — for each dimension in the view — is the whole game. "Compute Using" in the UI is just a friendly way of setting it.
graph TD
MARKS["Aggregated marks in the view
(Region x Month grid)"]
Q{"For each dimension:
addressing or partitioning?"}
ADDR["ADDRESSING (Month)
the calc moves ALONG this —
defines direction"]
PART["PARTITIONING (Region)
the calc RESETS within this —
defines the groups"]
RESULT["Running total walks month-by-month,
restarting for each region"]
MARKS --> Q
Q --> ADDR --> RESULT
Q --> PART --> RESULT
Partitioning vs addressing, the only concept that matters. Each dimension in the view is either something the calculation moves along (addressing — sets direction) or something it resets within (partitioning — sets the groups). A running total addressed by Month, partitioned by Region, walks month-by-month and starts over for each region. Change which dimension is addressing and the "same" calc moves a different way — which is exactly why rearranging the view changes the numbers.
Why your numbers change when you rearrange the view
The default "Table (Across)" / "Table (Down)" settings are tied to the view's layout — so moving a pill silently rewires the calculation. When you pick a quick table calc, Tableau defaults the direction to something like "Table (Across)," which means "address along whatever is laid out across." That's convenient until you swap Rows and Columns, because now "across" points at a different dimension and your running total runs the wrong way or your rank ranks the wrong thing — with no error, just a wrong number. The fix is to stop relying on layout-relative directions: set Compute Using → Specific Dimensions and explicitly check which dimensions are addressing. Then the calc is pinned to the fields, not the layout, and rearranging the view no longer breaks it. Layout-relative directions are the single biggest source of silent table-calc bugs.
The WINDOW functions and the common calcs
Under the hood, the quick table calcs are built from a family of functions that operate over the partition. Knowing them lets you write calcs the menu can't:
// Running total along the addressing dimension, within each partition
RUNNING_SUM(SUM([Sales]))
// Percent of total within the partition
SUM([Sales]) / TOTAL(SUM([Sales]))
// Rank within the partition (1 = highest)
RANK(SUM([Sales]))
// 3-month moving average (current mark + the 2 before it)
WINDOW_AVG(SUM([Sales]), -2, 0)
// Difference from the previous mark (e.g. month-over-month)
SUM([Sales]) - LOOKUP(SUM([Sales]), -1)
// Compare each mark to the partition's first mark (indexed growth)
SUM([Sales]) / LOOKUP(SUM([Sales]), FIRST())| You want | Function |
|---|---|
| Running / cumulative total | RUNNING_SUM |
| Percent of total in the partition | SUM(...) / TOTAL(SUM(...)) |
| Rank within a group | RANK, RANK_DENSE |
| Moving average / windowed aggregate | WINDOW_AVG (and WINDOW_SUM, etc.) |
| Compare to a neighbour (prior/next mark) | LOOKUP (with FIRST()/LAST()) |
| Position of the current mark | INDEX, SIZE |
Table calc vs. LOD: the recurring decision
This is the question that pairs with every table-calc discussion, and the answer is the same fork I draw in the LOD article from the other side. A table calculation computes on the marks already in the view — it's about their arrangement (running totals, rank, moving averages, comparisons between marks). An LOD expression computes in the query at a granularity you declare — it's about computing at a level not in the view (per-customer totals, percent of a coarser whole). If you find yourself building a fragile table calc to fake a different granularity, you want an LOD. If you're using an LOD and fighting to express "compared to the previous period," you want a table calc.
Always set Compute Using → Specific Dimensions on any non-trivial table calc. The quick-calc defaults ("Table Across/Down") are fine for a throwaway look, but for anything that ships, explicitly choosing which dimensions are addressing makes the calc robust to layout changes and — just as important — makes it readable by the next person, who can see exactly what it computes over instead of reverse-engineering it from the pill arrangement. Pinning the calc to fields rather than layout is the difference between a table calc that survives contact with a real dashboard and one that breaks the first time someone reorganizes the view.
What to carry away
A table calculation runs after aggregation, on the marks in the view, which is why it can express running totals, rank, moving averages, and mark-to-mark comparisons that raw aggregates can't. The one concept that unlocks all of it is partitioning versus addressing: every dimension in the view is either something the calc moves along (addressing, sets direction) or resets within (partitioning, sets the groups). "Compute Using" is just how you assign those roles.
The trap is the layout-relative default directions, which silently rewire your calculation when you rearrange the view — so pin every real table calc to Specific Dimensions and choose addressing explicitly. And keep the table-calc-vs-LOD fork straight: arrangement of marks in the view → table calc; a granularity not in the view → LOD. Once partitioning and addressing are second nature, the feature that gave inconsistent answers becomes the most expressive tool in Tableau. For where this sits in the engine, see Tableau internals.