Tableau Quiz: Common Table Calculations

10 questions · exam conditions

0:00

Common Table CalculationsQuestion 1 of 10

A worksheet contains monthly sales marks for January, March, and April. Sales are $100$ , $160$ , and $120$ , respectively. There is no February row in the data, and Show Missing Values is disabled. The marks are ordered chronologically, and the calculation is computed across Month.

What value does SUM([Sales]) - LOOKUP(SUM([Sales]), -1) return for March?

60

, because January is the preceding mark in the partition.

-60

, because the calculation subtracts March from January.

Null, because the immediately preceding calendar month is missing.

160

, because the lookup cannot move across a missing month.

← Back to quizzes

Tableau Quiz

Tableau Quiz: Common Table Calculations

Practice Common Table Calculations in Tableau with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Common Table Calculations, giving you a quick way to practice the rules, question types, and explanations that matter most for Tableau.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

What value does SUM([Sales]) - LOOKUP(SUM([Sales]), -1) return for March?

$60$ , because January is the preceding mark in the partition. (correct answer)
$-60$ , because the calculation subtracts March from January.
Null, because the immediately preceding calendar month is missing.
$160$ , because the lookup cannot move across a missing month.

Explanation: When working with Tableau table calculations like LOOKUP(), the critical distinction to understand is that these functions operate on the marks that exist in the view, not on an abstract calendar or continuous timeline. LOOKUP(expression, offset) moves a specified number of marks backward or forward within the current partition — it has no awareness of missing calendar periods. In this scenario, the view contains exactly three marks in chronological order: January (

100

), March (

160

), and April (

120

). When the calculation SUM([Sales]) - LOOKUP(SUM([Sales]), -1) evaluates for March, it looks one mark backward in the partition. The mark immediately behind March in the view is January. So the result is

160 - 100 = 60

, confirming that A is correct. Choice B gets the arithmetic backwards — the formula subtracts the prior mark from the current mark, not the other way around, so the result is positive

60

, not

-60

. Choice C reflects a common misconception: students assume LOOKUP is calendar-aware and would treat February's absence as a "gap," returning Null. But LOOKUP simply counts mark positions — it doesn't know February ever existed. Choice D misunderstands how LOOKUP handles missing data; it doesn't return the current mark's value when a neighbor is absent, and it doesn't "skip" in any special way — it just steps to the adjacent mark in the view. The key study tip: whenever you see LOOKUP on the exam, mentally number the visible marks in sequence. LOOKUP always moves by mark position, never by calendar distance. Missing rows that aren't shown simply don't exist to the function.

Question 2

A text view contains categories A, B, and C with sales of $100$ , $250$ , and $175$ . Category is sorted by SUM([Sales]) in descending order. INDEX() is computed down the resulting list.

What INDEX() value is assigned to category A?

$1$ , because A is alphabetically first among the categories.
$3$ , because A is third after the sales sort is applied. (correct answer)
$2$ , because two categories have higher aggregate sales than A.
$0$ , because table-calculation indexes begin with a zero offset.

Explanation: When Tableau evaluates INDEX(), it assigns row positions after all sorting has been applied — meaning the index reflects the final display order, not alphabetical order or any pre-sort sequence. Think of INDEX() as simply counting "what position am I in this list right now?" Here, the view sorts by SUM([Sales]) descending, so the order becomes: B (

250

) → C (

175

) → A (

100

). INDEX() then walks down that sorted list assigning

1

2

3

in order. Category A lands at position

3

, making B the correct answer. A is wrong because INDEX() has no awareness of alphabetical ordering. It doesn't care that "A" comes first in the alphabet — it only cares about the row's position in the current partition after sorting. C is tempting but subtly flawed: while it's true that two categories have higher sales than A, that reasoning describes rank, not index. INDEX() counts position directly; it doesn't compare values. The result happens to be

3

here, but the logic behind C conflates INDEX() with RANK(). D is wrong because Tableau's INDEX() is 1-based, starting at

1

for the first row — there is no zero offset. A useful study tip: whenever you see INDEX() on the exam, always ask yourself "what is the sort order at the time the table calculation runs?" Sort order transforms the underlying data sequence, and INDEX() simply numbers whatever sequence results. Confusing INDEX() with RANK() or assuming alphabetical default ordering are the two most common traps here.

Question 3

A profit view is ordered by month. The previous month's profit was $-50$ , and the current month's profit is $-30$ . A calculated field uses (SUM([Profit]) - LOOKUP(SUM([Profit]), -1)) / ABS(LOOKUP(SUM([Profit]), -1)) and is formatted as a percentage.

What percentage does the calculation return for the current month?

$-40\%$ , because the prior negative value determines the sign.
$-20\%$ , because profit remains below zero in the current month.
$20\%$ , because the absolute change is divided by the current value.
$40\%$ , because profit improved by $20$ relative to a base of $50$ . (correct answer)

Explanation: When you see a Tableau calculation involving LOOKUP and ABS, slow down and trace the arithmetic carefully — the function names tell you exactly what's happening, and the trap is usually in how signs interact. Here, the formula computes the percent change from the prior month:

\frac{\text{Current} - \text{Prior}}{|\text{Prior}|}

. Plugging in the values, current profit is

-30

and prior profit is

-50

, so you get

\frac{(-30) - (-50)}{|-50|} = \frac{20}{50} = 0.40

, or 40%. That's answer D. The result is positive because profit genuinely improved — moving from

-50

-30

is a gain of

20

units — and dividing by the absolute value of the prior period ensures the denominator is always positive, giving the sign of the numerator full control over the direction. Answer A claims the result is

-40\%

, confusing the negative sign of the prior value with the sign of the output. But ABS explicitly removes that negative from the denominator, so it can't drive the result negative. Answer B suggests

-20\%

, likely from dividing the raw change (

20

) by the current value (

-30

) — that's the wrong denominator and misreads the formula entirely. Answer C gets the magnitude wrong (

20\%

instead of

40\%

) by using the current value as the base rather than the prior value. A useful habit: whenever you see ABS wrapped around a LOOKUP, it's signaling that the base could be negative and needs normalizing. Always substitute real numbers before interpreting the sign of the result.

Question 4

A view contains Region, Year, and Month. An analyst creates WINDOW_SUM(SUM([Sales])). The calculation must sum across all months within each Region-Year combination and restart when either Region or Year changes.

When configuring Compute Using > Specific Dimensions, which setup satisfies the requirement?

Select Month; leave Region and Year unselected as partitioning dimensions. (correct answer)
Select Year and Month; leave Region unselected as the partitioning dimension.
Select Region and Month; leave Year unselected as the partitioning dimension.
Select Region, Year, and Month so every dimension is addressed.

Explanation: Whenever you see a question about WINDOW_SUM or any table calculation with Compute Using > Specific Dimensions, anchor yourself to this core rule: the dimensions you select are the ones the calculation moves across (the addressing dimensions), and the dimensions you leave unselected define the partitions — the boundaries where the calculation restarts. In this scenario, you want the window sum to sweep across all months within each Region-Year group, then restart when Region or Year changes. That means Region and Year must act as partitioning dimensions (unselected), and Month must act as the addressing dimension (selected). Selecting only Month achieves exactly this: Tableau computes WINDOW_SUM(SUM([Sales])) across every Month value, restarting fresh for each unique Region-Year combination. That's precisely answer A, the correct choice. Answer B selects Year alongside Month, which removes Year from the partition. The calculation would then sweep across both months and years within each Region group, collapsing year boundaries you need to preserve. Answer C selects Region and Month, removing Region from the partition, so the sum would span across regions — the opposite of restarting when Region changes. Answer D selects all three dimensions, leaving nothing to partition on, meaning Tableau computes one grand total across the entire view with no restarts at all. A reliable memory device: think of unselected dimensions as walls and selected dimensions as the path the calculation walks. You want walls around Region and Year, with Month as the only open path — so select only Month and let the walls do their job.

Question 5

A worksheet contains January, February, and March sales of $10$ , $20$ , and $30$ . RUNNING_SUM(SUM([Sales])) is computed across Month. The analyst also places LAST() = 0 on Filters, computed across Month, so that only the final month is displayed.

What running-sum value is displayed for March?

$30$ , because the table-calculation filter removes January and February first.
$50$ , because only February and March remain in the running window.
$60$ , because the hidden earlier marks still contribute to the calculation. (correct answer)
Null, because filtering to one mark invalidates the running-sum addressing.

Explanation: Whenever you see a question combining table calculations with filters in Tableau, the critical concept to understand is the order of operations: table calculations execute after filters, but dimension filters and most traditional filters remove data before table calculations run. However, LAST() = 0 is itself a table calculation used as a filter — and table-calculation filters behave differently. They hide marks visually but do not remove them from the underlying partition, so other table calculations still "see" the full dataset. This is exactly why C is correct. RUNNING_SUM(SUM([Sales])) computes across all three months — January (

10

), February (

20

), March (

30

) — producing a running sum of

10

30

60

respectively. Then LAST() = 0 filters the view to show only the last mark (March), but because this is a table-calculation filter, it merely hides January and February rather than excluding them from the calculation. March still displays its fully computed running sum of

60

. A is wrong because it assumes the filter removes earlier months before the running sum calculates — that's true for dimension filters, not table-calculation filters. B is wrong because it implies January was removed from the window, leaving only

20 + 30 = 50

; again, no marks are truly removed. D is wrong because hiding marks via a table-calculation filter does not invalidate the result — the calculation remains well-defined. The key study tip: always ask yourself what kind of filter is being applied. Dimension filters remove data before table calculations; table-calculation filters only hide results afterward, leaving the underlying computation intact.

Question 6

A worksheet displays four monthly marks in ascending order. Sales for January through April are $12$ , $18$ , $30$ , and $40$ . The calculation WINDOW_AVG(SUM([Sales]), -1, 1) is computed across Month.

What results are returned for February and April, respectively?

February is $15$ , and April is $35$ .
February is $20$ , and April is $35$ . (correct answer)
February is $20$ , and April is approximately $23.33$ .
February is $24$ , and April is $40$ .

Explanation: When you see WINDOW_AVG in Tableau, think of it as a sliding window that averages values across a specified range of rows relative to the current row. The syntax WINDOW_AVG(SUM([Sales]), -1, 1) means: for each row, average the current row plus one row before and one row after. For February (value

18

), the window includes January (

12

), February (

18

), and March (

30

). That gives

\frac{12 + 18 + 30}{3} = \frac{60}{3} = 20

. For April (value

40

), April is the last row, so there is no "row after." The window can only reach back one row to March (

30

) and include April itself (

40

). That gives

\frac{30 + 40}{2} = 35

. This makes B correct. Choice A gets February wrong by averaging only January and February —

\frac{12 + 18}{2} = 15

— as if the window were -1, 0 instead of -1, 1. Choice C correctly calculates February as

20

but then incorrectly includes all remaining values for April, averaging January through April as

\frac{12 + 18 + 30 + 40}{4} \approx 25

, confusing WINDOW_AVG with a running average. Choice D skips the window entirely, returning raw values rather than averages. The key study tip: at partition boundaries, Tableau's window functions don't pad with zeros or repeat values — they simply use whatever rows are available. Always check whether the current row is near an edge, because the window silently shrinks.

Question 7

A calculation PREVIOUS_VALUE(0) + SUM([Net Change]) is computed from top to bottom across three marks. Their net changes, in order, are $10$ , $-4$ , and $7$ .

What value does the calculation return for the third mark?

$13$ , because each mark adds its change to the prior calculated result. (correct answer)
$17$ , because the third mark adds its change to the first mark.
$3$ , because the third mark adds its change to the prior raw change.
$7$ , because PREVIOUS_VALUE resets to zero at every new mark.

Explanation: Whenever you see PREVIOUS_VALUE() in Tableau, the key concept to internalize is that it carries forward a running, accumulated result — not a raw field value — from one mark to the next, computed strictly in display order. Here's how the calculation unfolds for PREVIOUS_VALUE(0) + SUM([Net Change]). At the first mark, there is no prior result, so PREVIOUS_VALUE(0) returns its seed value,

0

. Adding the first net change gives

0 + 10 = 10

. At the second mark, PREVIOUS_VALUE(0) returns the previous calculated result, which is

10

. Adding

-4

gives

10 + (-4) = 6

. At the third mark, PREVIOUS_VALUE(0) returns

6

, and adding

7

yields

6 + 7 = 13

. That confirms A is correct: each mark accumulates by adding its change to the prior calculated result, producing a running total. B is wrong because it assumes the third mark references the first mark's output (

10 + 7 = 17

), skipping the second mark entirely — PREVIOUS_VALUE always references the immediately preceding mark, not any arbitrary one. C is wrong because it treats the "previous value" as the prior raw net change (

-4 + 7 = 3

) rather than the accumulated result. D is wrong because PREVIOUS_VALUE does not reset to its seed at every mark — it only uses the seed for the very first mark. A useful mental model: think of PREVIOUS_VALUE() like a bank balance. Each row deposits or withdraws from whatever balance was left after the previous transaction — it never starts from zero again mid-sequence.

Question 8

A view displays January through May in ascending order. Monthly sales are $10$ , $20$ , $30$ , $40$ , and $50$ . The calculation WINDOW_SUM(SUM([Sales]), -2, 0) is computed across Month in one partition.

Which pair gives the calculation results for April and February, respectively?

April is $120$ , and February is $30$ .
April is $90$ , and February is $60$ .
April is $90$ , and February is $30$ . (correct answer)
April is $70$ , and February is $30$ .

Explanation: When you see WINDOW_SUM(SUM([Sales]), -2, 0) in Tableau, the key is understanding the offset parameters. The first number (

-2

) tells Tableau to look two rows back from the current row, and the second number (

0

) means the current row itself. So for each mark, Tableau sums the current row plus the two preceding rows. With months ordered January through May and sales of

10, 20, 30, 40, 50

, here's how the window shifts per row:

January (position 1): only one row exists before it, so $10$
February (position 2): $10 + 20 = 30$
March (position 3): $10 + 20 + 30 = 60$
April (position 4): $20 + 30 + 40 = 90$
May (position 5): $30 + 40 + 50 = 120$

April gives

90

and February gives

30

, confirming C is correct. Answer A is wrong because it swaps the values —

120

is May's result, not April's. This is a classic trap where students match the right numbers to the wrong months. Answer B reverses the two:

60

actually belongs to March, not February. Answer D arrives at

70

for April, which would only be correct if the window were

-1, 0

(two rows instead of three), suggesting a misread of the offset parameters. As a study habit, always trace through the window offsets row by row on a small dataset — it takes 60 seconds and eliminates nearly every WINDOW function mistake on the exam.

Question 9

Monthly marks are sorted in descending chronological order: April, March, February, and January. Their sales are $40$ , $30$ , $20$ , and $10$ . The calculation WINDOW_SUM(SUM([Sales]), 0, LAST()) is computed across Month.

What value does the calculation return at the March mark?

$90$ , because March and later calendar months are included.
$100$ , because LAST() causes the entire partition to be summed.
$60$ , because the window follows the displayed order from March through January. (correct answer)
$50$ , because only March and its immediately following mark are included.

Explanation: When working with Tableau window functions, the key is understanding that FIRST() and LAST() are relative to the current row's position in the partition's displayed order — not absolute calendar positions. WINDOW_SUM(SUM([Sales]), 0, LAST()) means: start at the current mark (offset

0

) and extend to the last mark in the partition. Since the months are displayed in descending order — April (rank 1), March (rank 2), February (rank 3), January (rank 4) — "last" means January, the final row in that displayed sequence. At the March mark, the window spans from March through the end of the displayed order: March (

30

) + February (

20

) + January (

10

) =

\mathbf{60}

. That confirms C is correct. Choice A is tempting but wrong: it assumes "later" means later on the calendar, so it includes April. But April appears before March in the displayed order, and the window only looks forward (toward the last row), not backward. Choice B reflects a common misconception that LAST() always returns the full partition total — it doesn't. LAST() is a relative offset from the current row to the final row, so the window shrinks as you move down. At April's mark, the sum would be

100

, but not at March's. Choice D assumes LAST() means "one row forward," confusing it with an offset of

1

rather than the distance to the partition's end. Your study tip: always sketch the displayed row order and mentally place your "cursor" at the mark in question — then count forward to LAST() to identify which rows fall in the window.

Question 10

Four products have sales of $200$ , $150$ , $150$ , and $100$ . A descending table calculation ranks the products by aggregate sales.

What rank does the $100$ product receive with RANK(SUM([Sales]), 'desc'), and what rank would it receive if the calculation were changed to RANK_DENSE?

RANK returns $3$ , while RANK_DENSE returns $4$ .
RANK returns $3$ , while RANK_DENSE returns $3$ .
RANK returns $4$ , while RANK_DENSE returns $4$ .
RANK returns $4$ , while RANK_DENSE returns $3$ . (correct answer)

Explanation: Whenever you see a question about ranking functions in Tableau, the key is understanding how each function handles ties — because that's the only place they behave differently. Here's the setup: four products have sales of

200

150

150

, and

100

. In descending order, the ranks work like this. The

200

product is clearly first. The two

150

products are tied — and this is where the functions diverge. With RANK, ties share the lowest rank they would collectively occupy. Both

150

products tie for rank

2

, but since they consume two positions (2nd and 3rd), the next product skips ahead to rank

4

. So the

100

product receives a rank of

4

. With RANK_DENSE, ties share a rank but no positions are skipped — the next distinct value simply gets the next consecutive rank. So

200

is rank

1

, both

150

s share rank

2

, and

100

receives rank

3

. That makes D correct. Choice A incorrectly gives RANK a result of

3

, which would only happen if ties didn't consume extra positions — that's actually how RANK_DENSE works, not RANK. Choice B assigns

3

to both functions, ignoring the gap that RANK creates entirely. Choice C assigns

4

to both, missing the fact that RANK_DENSE never skips positions after a tie. A useful memory trick: think of RANK_DENSE as compact — no gaps, no skips. Standard RANK mirrors how Olympic medals work: two silver medalists mean no bronze is awarded, pushing the next competitor to fourth place.