Troubleshooting Table Calcs - Tableau

1. Which change most directly allows the moving window to continue across year boundaries for each region?
   Answer: Change the computation to Table Across so that the quarter sequence spans the yearly column panes. Whenever you see a question about table calculations in Tableau, focus on two distinct concepts: addressing (which dimensions define the moving direction) and partitioning (which dimensions reset the calculation). These two choices together determine where a moving average continues and where it starts over. In this scenario, the view has Year and Quarter on Columns and Region on Rows. With Pane Across configured, Tableau treats each individual pane — defined by Year — as its own independent window. So when a new year begins, the moving average resets, explaining why Q1 of each year only uses one quarter. To let the window flow continuously across year boundaries, you need the calculation to treat the entire row of quarters (spanning multiple years) as one unbroken sequence. Table Across does exactly this: it addresses across the entire table width, crossing all Year/Quarter columns within the same row, so the moving average carries forward from one year into the next. Choice B is wrong because Pane Down would address the calculation vertically across Regions, meaning quarters from different regions — not different years — would bleed together, which is nonsensical here. Choice C is a trap: resorting quarters doesn't change the addressing scope at all; Pane Across still restarts at each pane regardless of sort order. Choice D describes an inverted addressing scheme where Region is addressed and Quarter is partitioned — this would calculate moving averages across regions within each quarter, which is the opposite of what you want. As a study tip, always ask yourself two questions about any table calculation: what am I moving along? (addressing) and what creates a fresh start? (partitioning). Matching those answers to the visual structure of your view is the key skill Tableau tests repeatedly.
2. Which change most directly corrects the result while preserving one cumulative sequence for the worksheet?
   Answer: Sort Product by SUM([Sales]) descending and continue addressing the running calculation along Product. Whenever you see a question about RUNNING_SUM or other table calculations behaving unexpectedly, focus on two things: addressing (which dimension the calculation moves across) and order (the sequence in which it moves). A running sum accumulates values in exactly the order Tableau encounters the dimension members — so if products appear alphabetically, the accumulation follows alphabetical order, not sales magnitude. The fix in answer B is direct: sorting Product by SUM([Sales]) descending forces Tableau to lay out dimension members from highest to lowest sales before the table calculation runs. Since RUNNING_SUM still addresses along Product, it now accumulates in the correct Pareto sequence — largest contributor first — without requiring any structural change to the calculation itself. One continuous cumulative sequence is preserved across the entire worksheet. Answer A is wrong on two levels: Percent of Total is a different calculation entirely and doesn't produce a cumulative Pareto line, and keeping alphabetical order defeats the whole purpose of the fix. Answer C misunderstands partitioning — partitioning by Product means the calculation restarts for each product individually, producing isolated totals rather than a single running sequence across products. That breaks the cumulative structure entirely. Answer D is a misconception about field type; converting a dimension to continuous changes how Tableau renders it on an axis but does not reorder the table calculation's traversal based on sales magnitude. The study tip to remember: sort order drives table calculation order. When a running calculation accumulates in the wrong sequence, the first thing to check is how the underlying dimension is sorted — not the calculation's addressing or partitioning.
3. How should the calculation be configured using Specific Dimensions?
   Answer: Address by Year and Month in chronological order, leaving Category as a partitioning dimension. When working with table calculations in Tableau, the core concept to master is the addressing vs. partitioning distinction. Addressing dimensions define how the calculation moves (the direction of computation), while partitioning dimensions define what restarts the calculation. Any dimension left as a partitioning dimension causes the calculation to reset independently for each member. The requirement here is to let the percent-difference flow continuously across months and years — meaning January should look back to the previous December — while still resetting per category. To achieve this, you need Year and Month both in the addressing role, arranged chronologically. This tells Tableau to step through time without interruption. Category remains a partitioning dimension, so each category is still evaluated independently. That's exactly what option C describes, making it the correct configuration. Option A fails because leaving Year as a partitioning dimension is precisely what causes the calculation to restart each January — the original problem you're trying to solve. Option B compounds the error by adding Category to the addressing dimensions; since Category should drive independent resets, it must stay as a partitioning dimension, not an addressing one. Option D is the most conceptually backwards choice: addressing by Year and Category while leaving Month as the only partitioning dimension means the calculation moves across categories (meaningless for this comparison) and resets for every individual month — the opposite of continuous time flow. A reliable study tip: whenever a calculation "restarts too early," look at what's partitioning and ask whether it should be. If a dimension needs to flow through continuously, move it into addressing. If it needs to reset independently, keep it partitioning.
4. What is the most likely explanation for the February result?
   Answer: The descending order makes March the previous displayed mark, so Tableau computes February sales minus March sales. Whenever you see a question about table calculations in Tableau, your first instinct should be to ask: in what order are marks actually displayed? Table calculations like Difference from Previous move sequentially through marks exactly as they appear on the view — they do not re-sort data chronologically behind the scenes. Here, the view displays months in descending order: March, then February, then January. When Tableau computes Difference from Previous going down that list, it treats March as the mark that comes before February. So the calculation produces $120 - 90 = 30$, not the chronological $120 - 100 = 20$ the analyst expected. This confirms C is correct — the descending sort places March immediately before February in the displayed sequence, and that's the "previous" Tableau uses. A is wrong because Difference from Previous never involves partition averages — it simply subtracts one adjacent mark from the next. Averages aren't part of this calculation at all. B is wrong because Tableau does not ignore the displayed sort or jump to the earliest mark in the partition; it strictly follows display order, moving one step at a time. D is wrong because whether a date field is discrete or continuous affects how it's displayed on shelves, not how a table calculation traverses marks — and grand totals are never the comparison point for Difference from Previous. A reliable study tip: before interpreting any table calculation result, sketch out the marks in the exact order they appear on screen. That sequence is the sequence Tableau uses — sort direction included.
5. Which approach most reliably preserves the intended calculation when the layout changes?
   Answer: Use Specific Dimensions with State addressed and Region retained as an explicit partitioning dimension. When working with Tableau table calculations, the key distinction to understand is the difference between addressing (which dimensions define the computation direction) and partitioning (which dimensions restart/isolate the calculation). Questions like this are testing whether you know how to make those boundaries explicit rather than relying on structural shortcuts that break when the view changes. Using Specific Dimensions is the most robust approach precisely because you name each dimension's role directly. In option C, you address State — meaning the running total accumulates across State values — while Region acts as the partition, restarting the total for each Region. This relationship is locked into the calculation definition itself, so rearranging fields on Rows or Columns doesn't disturb it. Option A fails because Pane Down is a relative addressing mode — pane boundaries are determined by whatever dimensions happen to divide the view into panes at that moment. Move a field, and the pane structure changes, taking your calculation behavior with it. That's exactly the problem described in the passage. Option B is wrong for a similar reason. Table Down accumulates across the entire table dimension and has no automatic awareness of Region as a partitioning boundary — Tableau doesn't "detect" intent. This would likely collapse all regions into one continuous total. Option D reverses the roles: addressing Region and partitioning by State would accumulate across regions and restart per state — the opposite of what's required. The study tip here: whenever a question describes a calculation that breaks after a layout change, that's a signal to reach for Specific Dimensions. Relative modes (Pane, Table) are view-dependent; Specific Dimensions are definition-dependent — and definitions travel with the calculation.
6. Why can changing table-calculation partitioning alone not enforce the required prior-product result?
   Answer: Partitioning determines which marks belong together, but the tied products still need a deterministic secondary ordering rule. When working with LOOKUP() and tied values in Tableau, the key distinction to understand is the difference between partitioning and ordering in table calculations — they serve completely different roles. Partitioning defines which marks are grouped together for the calculation to operate across. Ordering defines the sequence in which those marks are traversed. LOOKUP(SUM([Sales]), -1) walks backward through whatever sequence the ordering establishes. Here's the problem: when two products have identical sales values, the sort on SUM([Sales]) descending cannot deterministically distinguish their positions. Tableau has no instruction for which tied product lands in row 3 versus row 4, so the "prior product" that LOOKUP fetches becomes unpredictable. The fix requires a secondary sort — in this case, Product ID ascending — added to the table calculation's ordering, not its partitioning. That's exactly what D captures: partitioning handles membership, but tied marks still need a deterministic ordering rule to produce a reliable LOOKUP result. A is wrong because descending measure sorts do not automatically reverse Product ID values — sort direction on one field doesn't cascade onto unrelated dimensions like that. B is wrong on two counts: partitioning does not auto-sort by Product ID, and LOOKUP does respect dimension ordering — that's precisely what you'd use to fix this. C is wrong because partitioning has no effect on how sales are aggregated; it only scopes the calculation, not the measure formula itself. As a study tip, remember: in Tableau table calculations, partitioning = who belongs together, ordering = who comes first. Tie-breaking problems almost always live in the ordering configuration, not partitioning.
7. Which Specific Dimensions configuration best meets the requirement?
   Answer: Check Category for addressing and leave Segment unchecked so that each segment defines a partition. Whenever you see a question about Table Calculations in Tableau, the critical distinction is between addressing (the dimensions the calculation moves across) and partitioning (the dimensions that define independent groups). Any dimension you check under Specific Dimensions becomes part of the addressing — the remaining unchecked dimensions automatically become the partition. Here, the goal is for Sales percentages to sum to $100\%$ within each Segment separately, meaning Segment must act as the partition, not as part of the addressing. To make Segment a partition, you must leave it unchecked. Category, however, is the dimension the percent-of-total calculation needs to move across — so Category must be checked for addressing. That logic confirms A as correct: checking Category and leaving Segment unchecked causes each Segment to define its own independent partition, and the percentages across Category marks within each Segment will sum to $100\%$. Choice B gets the roles exactly backwards — checking Segment for addressing and leaving Category unchecked makes Category the partition, so percentages would total $100\%$ across segments for each category, which is the original problem you're trying to fix. Choice C checks both dimensions, collapsing everything into a single addressed partition that spans all segments and categories — percentages would still sum to one grand $100\%$ total, not per-segment totals. Choice D leaves both unchecked, making every individual mark its own partition, so each mark trivially shows $100\%$ with no meaningful aggregation. A useful memory anchor: checked = addressed (moves across), unchecked = partitioned (resets). When you need a dimension to create separate groups, leave it unchecked.
8. What change is necessary to make each regional sequence end at $100\%$?
   Answer: Configure the nested total to use the same regional partition as the running-sum numerator. Whenever you encounter a Pareto chart calculation in Tableau that combines RUNNING_SUM with TOTAL, the critical concept being tested is table calculation partitioning — specifically, how the "partition" (the scope over which a calculation resets or aggregates) must align across both functions for the result to be meaningful. Here, the numerator RUNNING_SUM(SUM([Sales])) restarts per Region because its partition is set to Region. However, TOTAL(SUM([Sales])) is still partitioned over the entire view, so it returns the grand total of all regions — a number larger than any single region's total. Dividing a regional running sum by a cross-region grand total means the final value in each region will be some fraction less than $100\%$, proportional only to that region's share of all sales. The fix is answer B: nest the TOTAL calculation inside the same regional partition, so it returns only the total sales for the current region. Each regional sequence then divides its running sum by its own regional total, correctly reaching $100\%$ at the end. A is wrong because resorting by total sales changes display order but does nothing to the partition logic — the denominator still spans the full view. C is a red herring; reversing product sort alters which products appear first but cannot reconcile a mismatched partition scope. D describes the opposite of what's needed — addressing the running sum across Region would break the per-region restart, and keeping the entire-view denominator perpetuates the exact problem described. As a study tip: whenever a Tableau Pareto doesn't reach $100\%$, immediately check whether your TOTAL partition matches your RUNNING_SUM partition — mismatched scopes are the most common cause.
9. Which configuration should the analyst use to produce an independent monthly running total for each category?
   Answer: Check Month only and leave Category unchecked, making each category a separate calculation partition. Whenever you see a question about table calculations in Tableau, focus on two key concepts: partitioning and addressing. The fields you check in "Specific Dimensions" define the partition — the boundary within which the calculation restarts. The unchecked fields become the addressing — the direction the calculation moves across marks. To get an independent running total for each category, you need the calculation to restart every time the category changes. That means Category must define the partition boundary. Checking Month only (answer B) does exactly this: Month becomes the addressing (the calculation moves across months), and Category — being unchecked — becomes the partitioning field. The running total resets for each category, giving you one clean, independent accumulation per colored line. Answer A gets the logic completely backwards. Checking Category only makes Month the partition, so the calculation restarts with every month rather than every category — the opposite of what you want. Answer C reflects a common misconception: sort order affects the sequence of marks within an addressing direction, but it has no impact on where partitions begin and end. Rearranging categories won't cause the running total to reset per category. Answer D — unchecking everything — removes all partitioning structure entirely, causing Tableau to treat the entire view as one giant partition and accumulate values across all category-month combinations without any meaningful restart. A useful memory trick: checked = addressing (the path), unchecked = partitioning (the fence). When you want independence per dimension, leave that dimension unchecked so it acts as the fence that isolates each group's calculation.
10. Which revision most directly corrects the label without changing the sort?
    Answer: Use FIRST() = 0, because the newest month is the first addressed mark in descending order. When Tableau computes table calculations, it assigns addressing based on the sort order of the view — not the underlying data order. This question tests whether you understand how FIRST(), LAST(), and INDEX() are anchored relative to the addressed marks after sorting is applied. Because the worksheet is sorted newest to oldest, the newest month sits at the first addressed position in the partition, and the oldest month sits at the last. LAST() = 0 returns TRUE for the mark that is zero steps from the end of the partition — which, in this descending sort, is the oldest month. That's exactly the bug described. Choosing FIRST() = 0 instead correctly identifies the mark that is zero steps from the beginning of the partition, which is the newest month in a descending sort. Answer A is correct. Answer B is tempting but wrong. INDEX() = 1 would also point to the first addressed mark, but INDEX() is 1-based, so the first mark returns 1, not 0 — and more importantly, this question is specifically testing FIRST()/LAST() mechanics, not index numbering. Answer C is logically backwards. LAST() = SIZE() - 1 would evaluate to TRUE for the mark that is SIZE() - 1 steps from the end — that's actually the first mark, but this is a convoluted and unreliable way to express it. It conflates FIRST() and LAST() semantics unnecessarily. Answer D is nonsensical. SIZE() returns the count of marks in the partition and is never equal to 1 unless there's only one mark — it has no positional meaning. Remember: **FIRST() counts from the top of your sort; LAST() counts from the bottom.** When sort order flips, so does which function you need.

Start this quiz