Tableau Quiz: Troubleshooting Table Calcs
10 questions · exam conditions
0:00
Troubleshooting Table CalcsQuestion 1 of 10

A worksheet displays Product on Rows and RUNNING_SUM(SUM([Sales])) as a Pareto-style cumulative measure. The analyst expects products to accumulate from highest sales to lowest sales, but the cumulative values follow product names alphabetically.

Which change most directly corrects the result while preserving one cumulative sequence for the worksheet?

Change the table calculation from Running Total to Percent of Total and retain the alphabetical product order.
Sort Product by SUM([Sales]) descending and continue addressing the running calculation along Product.
Partition the calculation by Product so that each product begins with its own accumulated sales value.
Convert Product to a continuous field so that Tableau uses sales magnitude as the calculation order.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Troubleshooting Table Calcs

Practice Troubleshooting Table Calcs 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 Troubleshooting Table Calcs, 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

A worksheet displays Product on Rows and RUNNING_SUM(SUM([Sales])) as a Pareto-style cumulative measure. The analyst expects products to accumulate from highest sales to lowest sales, but the cumulative values follow product names alphabetically.

Which change most directly corrects the result while preserving one cumulative sequence for the worksheet?

  1. Change the table calculation from Running Total to Percent of Total and retain the alphabetical product order.
  2. Sort Product by SUM([Sales]) descending and continue addressing the running calculation along Product. (correct answer)
  3. Partition the calculation by Product so that each product begins with its own accumulated sales value.
  4. Convert Product to a continuous field so that Tableau uses sales magnitude as the calculation order.
Explanation: 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.

Question 2

A crosstab has Category on Rows and discrete Year followed by Month on Columns. A month-over-month percent-difference calculation currently restarts at January of every year. The requirement is to compare January with December of the preceding year while still calculating each category independently.

How should the calculation be configured using Specific Dimensions?

  1. Address by Month only, leaving both Year and Category as partitioning dimensions.
  2. Address by Category and Month, leaving Year as the only partitioning dimension.
  3. Address by Year and Month in chronological order, leaving Category as a partitioning dimension. (correct answer)
  4. Address by Category and Year, leaving Month as the only partitioning dimension.
Explanation: 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.

Question 3

A worksheet places discrete Year and Quarter on Columns and Region on Rows. A four-quarter moving average is configured as Pane Across. The value for the first quarter of each year uses only that quarter, even though the preceding year's final three quarters are visible.

Which change most directly allows the moving window to continue across year boundaries for each region?

  1. Change the computation to Table Across so that the quarter sequence spans the yearly column panes. (correct answer)
  2. Change the computation to Pane Down so that each year uses quarters from the preceding region.
  3. Sort Quarter descending within each year while retaining Pane Across as the computation direction.
  4. Partition by Quarter and address Region so that corresponding quarters share one moving window.
Explanation: 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.

Question 4

Products are sorted by SUM([Sales]) descending, and LOOKUP(SUM([Sales]), -1) is used to display the prior product's sales. Two products have equal sales, but the business rule requires Product ID ascending to determine which tied product comes first. The current sort specifies only descending sales.

Why can changing table-calculation partitioning alone not enforce the required prior-product result?

  1. Partitioning controls lookup direction, but descending measure sorts always reverse Product ID values.
  2. Partitioning automatically sorts tied products by Product ID, but LOOKUP ignores all dimension sorts.
  3. Partitioning changes the sales aggregation, so the tied products must be converted to separate measures first.
  4. Partitioning determines which marks belong together, but the tied products still need a deterministic secondary ordering rule. (correct answer)
Explanation: 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.

Question 5

A running-total view initially has Region followed by State on Rows and uses Pane Down. It restarts correctly for each region. After the analyst rearranges the dimensions in the view, the totals restart at different locations even though the calculation formula is unchanged. The requirement is always to accumulate across State separately for each Region.

Which approach most reliably preserves the intended calculation when the layout changes?

  1. Continue using Pane Down, because pane boundaries remain tied to Region regardless of field placement.
  2. Use Table Down, because it automatically detects Region as the required partitioning dimension.
  3. Use Specific Dimensions with State addressed and Region retained as an explicit partitioning dimension. (correct answer)
  4. Use Specific Dimensions with Region addressed and State retained as an explicit partitioning dimension.
Explanation: 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.

Question 6

An analyst creates a regional Pareto calculation using RUNNING_SUM(SUM([Sales])) / TOTAL(SUM([Sales])). The running sum correctly restarts for each Region, but the final product in each region ends below 100%100\%. Investigation shows that TOTAL(SUM([Sales])) is computed over the entire view.

What change is necessary to make each regional sequence end at 100%100\%?

  1. Sort Region by total sales while leaving the numerator and denominator partitions unchanged.
  2. Configure the nested total to use the same regional partition as the running-sum numerator. (correct answer)
  3. Reverse the product sort so that the smallest products occur at the end of each region.
  4. Address the running sum across Region while retaining an entire-view denominator for total sales.
Explanation: 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%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%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%100\%, immediately check whether your TOTAL partition matches your RUNNING_SUM partition — mismatched scopes are the most common cause.

Question 7

A view lists three months in descending date order: March sales are 9090, February sales are 120120, and January sales are 100100. A Difference from Previous table calculation is computed down the displayed months. February shows 3030, although the analyst expected the chronological month-over-month change of 2020.

What is the most likely explanation for the February result?

  1. The calculation is partitioned by month, so Tableau subtracts the overall monthly average from February sales.
  2. The calculation ignores the displayed sort and always compares February with the earliest month in the partition.
  3. The descending order makes March the previous displayed mark, so Tableau computes February sales minus March sales. (correct answer)
  4. The date field is discrete, so Tableau compares February with the grand total rather than an adjacent month.
Explanation: 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=30120 - 90 = 30, not the chronological 120−100=20120 - 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.

Question 8

A line view has Month on Columns, Sales on Rows, and Category on Color. A running-total calculation uses Specific Dimensions with both Month and Category checked. Instead of restarting for each colored line, some categories inherit accumulated values from other categories.

Which configuration should the analyst use to produce an independent monthly running total for each category?

  1. Check Category only and leave Month unchecked, making each month a separate calculation partition.
  2. Check Month only and leave Category unchecked, making each category a separate calculation partition. (correct answer)
  3. Keep Month and Category checked, but sort Category descending before sorting the monthly values.
  4. Leave Month and Category unchecked, allowing every category-month mark to calculate independently.
Explanation: 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.

Question 9

Segment and Category are nested on Rows, and Sales is displayed as Percent of Total. Every category currently shows its percentage of sales across all segments. The requirement is for category percentages to total 100%100\% separately within each segment.

Which Specific Dimensions configuration best meets the requirement?

  1. Check Category for addressing and leave Segment unchecked so that each segment defines a partition. (correct answer)
  2. Check Segment for addressing and leave Category unchecked so that each category defines a partition.
  3. Check both Segment and Category so that all category marks belong to one addressed partition.
  4. Leave both Segment and Category unchecked so that each displayed mark becomes a separate partition.
Explanation: 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%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%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%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%100\% total, not per-segment totals. Choice D leaves both unchecked, making every individual mark its own partition, so each mark trivially shows 100%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.

Question 10

A worksheet is intentionally sorted from newest month to oldest month. A label calculation uses LAST() = 0 to identify the latest month, but the label appears on the oldest month. The descending display order must be preserved.

Which revision most directly corrects the label without changing the sort?

  1. Use FIRST() = 0, because the newest month is the first addressed mark in descending order. (correct answer)
  2. Use INDEX() = 1, because the newest month receives the first index value in the addressed partition.
  3. Use LAST() = SIZE() - 1, because the newest month is the mark farthest from the partition endpoint.
  4. Use SIZE() = 1, because the newest month is the first member of every date partition.
Explanation: 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.