Common Table Calculations - Tableau

What value does the calculation return at the March mark?
Answer: $60$ , because the window follows the displayed order from March through January. 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.
When configuring Compute Using > Specific Dimensions, which setup satisfies the requirement?
Answer: Select Month; leave Region and Year unselected as partitioning dimensions. 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.
What value does the calculation return for the third mark?
Answer: $13$ , because each mark adds its change to the prior calculated result. 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.
What results are returned for February and April, respectively?
Answer: February is $20$ , and April is $35$ . 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.
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?
Answer: RANK returns $4$ , while RANK_DENSE returns $3$ . 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.
What INDEX() value is assigned to category A?
Answer: $3$ , because A is third after the sales sort is applied. 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.
What value does SUM([Sales]) - LOOKUP(SUM([Sales]), -1) return for March?
Answer: $60$ , because January is the preceding mark in the partition. 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.
What percentage does the calculation return for the current month?
Answer: $40\%$ , because profit improved by $20$ relative to a base of $50$ . 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$ to $-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.
Which pair gives the calculation results for April and February, respectively?
Answer: April is $90$ , and February is $30$ . 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.
What running-sum value is displayed for March?
Answer: $60$ , because the hidden earlier marks still contribute to the calculation. 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.

Start this quiz