Tableau Quiz: Understanding Lod Expressions
15 questions · exam conditions
0:00
Understanding Lod ExpressionsQuestion 1 of 15

A FIXED Region sum is shown by Region. Add State to the view.

State totals replace region
Values recalc at state level
Repeat region total per state
LOD is ignored for state rows
← Back to quizzes

Tableau Quiz

Tableau Quiz: Understanding Lod Expressions

Practice Understanding Lod Expressions 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 Understanding Lod Expressions, 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 FIXED Region sum is shown by Region. Add State to the view.

  1. State totals replace region
  2. Values recalc at state level
  3. Repeat region total per state (correct answer)
  4. LOD is ignored for state rows
Explanation: With FIXED [Region], the sum is calculated once for each region before State is added to the view. Adding State doesn't change that level of detail, so each state in a region displays the same region total. The tempting wrong answer is that values recalc at state level, but FIXED keeps the region grain and won't split the total by state.

Question 2

Which situation best calls for an LOD expression?

  1. Rank within a partition
  2. Different grains in a ratio (correct answer)
  3. Moving average over time
  4. Custom currency formatting
Explanation: A ratio that mixes two detail levels needs an LOD expression to set the aggregation level independently. For example, total sales per region divided by number of stores uses a fixed LOD to keep one grain while the other is more granular. Rank within a partition is the tempting wrong answer, but that's a table calculation, which only operates on values already returned by the query.

Question 3

Category view: want average of each order's sales within that category.

  1. No LOD at view grain
  2. FIXED at Order ID
  3. EXCLUDE at Category
  4. INCLUDE at Order ID (correct answer)
Explanation: With the view at Category, an INCLUDE Order ID LOD computes total sales at the order level first, then averages those order totals inside each category, giving the average order value by category. A FIXED Order ID is the tempting mistake because it would compute order totals overall, ignoring the category view, so it cannot produce per-category averages.

Question 4

View Region x Product; Product filter active. Need region totals for filtered products.

  1. EXCLUDE [Product] (correct answer)
  2. FIXED [Region] sum
  3. INCLUDE [Product]
  4. No LOD: SUM(Sales)
Explanation: EXCLUDE [Product] computes sum(Sales) at the Region level while still honoring the active Product filter, so you get region totals only for the filtered products. The tempting FIXED [Region] sum is wrong because FIXED LODs ignore normal filters like the Product filter; it would include products that have been filtered out. INCLUDE [Product] stays too fine-grained, and plain SUM(Sales) is at the product grain.

Question 5

View is filtered to West. Need total customers across all regions.

  1. FIXED for all data (correct answer)
  2. INCLUDE [Region]
  3. EXCLUDE [Region]
  4. No LOD, current view
Explanation: A FIXED LOD like {FIXED : COUNTD(Customer ID)} computes the total across all regions because it is evaluated before the West view filter, so the filter doesn't shrink it. The tempting choice is INCLUDE [Region], which adds Region to the level of detail but still runs after the filter, so it would return only West customers, not the all-region total.

Question 6

A dashboard uses FIXED[Customer]:SUM([Sales]){ FIXED [Customer] : SUM([Sales]) } to calculate customer sales. A State filter is applied. Users report that customer totals still include sales from states they excluded.

Which change is most appropriate if the customer totals must be recomputed from only the selected states?

  1. Convert the State filter to a context filter so it is evaluated before the FIXED expression. (correct answer)
  2. Convert the State filter to a measure filter so it is evaluated before the FIXED expression.
  3. Replace FIXED with EXCLUDE State so the calculation retains all states selected by users.
  4. Add State to Detail so the existing FIXED expression inherits the worksheet's granularity.
Explanation: Whenever you see a question about LOD expressions behaving unexpectedly with filters, the key concept to understand is Tableau's order of operations. FIXED LOD expressions are computed before dimension filters in Tableau's execution pipeline — meaning a standard State filter has no effect on what data the FIXED expression sees. It will always aggregate across all states regardless of what users select. The fix is to promote the State filter to a context filter. Context filters are evaluated first in the order of operations — before FIXED LOD expressions — so the FIXED calculation only sees the data that survives the context filter. Once you right-click the State filter and select "Add to Context," {FIXED [Customer] : SUM([Sales])}\{ \text{FIXED [Customer] : SUM([Sales])} \} will correctly compute customer totals using only the selected states. That makes A the correct answer. B is wrong because "measure filter" is not a real filter type in Tableau's order of operations framework. Measure filters (filters on aggregated values) are applied after LOD expressions, which would make the problem worse, not better. C is wrong because EXCLUDE is used to remove specific dimensions from a view-level granularity — it doesn't help when the problem is that a dimension filter is being ignored entirely. EXCLUDE would still be overridden by dimensions higher in the LOD hierarchy. D is wrong because adding State to Detail changes the view's granularity but has no effect on how a FIXED expression is computed. FIXED ignores view granularity by definition. Study tip: Memorize Tableau's order of operations as a sequence: Context Filters → FIXED LODs → Dimension Filters → INCLUDE/EXCLUDE LODs → Measure Filters. Any time a FIXED expression seems to ignore a filter, your first instinct should be "make it a context filter."

Question 7

An analyst defines lifetime customer sales as FIXED[Customer]:SUM([Sales]){ FIXED [Customer] : SUM([Sales]) }. The worksheet has an ordinary Order Date dimension filter limited to the current year. A customer made purchases both this year and in prior years.

What should the analyst expect from the lifetime-sales value under this configuration?

  1. It includes only current-year sales because all date filters are evaluated before FIXED expressions.
  2. It includes prior-year and current-year sales because the ordinary date filter is evaluated after the FIXED expression. (correct answer)
  3. It includes only prior-year sales because the visible current-year rows are removed from the LOD calculation.
  4. It becomes null because FIXED expressions cannot be combined with dimension filters on dates.
Explanation: Whenever you see a question involving FIXED level-of-detail expressions and filters, your first instinct should be to recall Tableau's order of operations. Filters are not all created equal — their position in the execution pipeline determines what data an LOD expression actually sees. FIXED expressions sit above dimension filters in Tableau's order of operations. This means a FIXED calculation is computed against the full underlying dataset first, before any dimension filter (like a date filter added to the worksheet's filter shelf) is applied to trim the view. So when you write {FIXED [Customer]:SUM([Sales])}\{ FIXED\ [Customer] : SUM([Sales]) \}, Tableau aggregates all sales for each customer across every year in the data — then the current-year filter narrows what rows are displayed, but it cannot reach back and alter the already-computed FIXED result. That's why B is correct: the lifetime-sales value includes both prior-year and current-year purchases, exactly as intended for a true "lifetime" metric. A has the causality backwards — dimension filters are evaluated after FIXED expressions, not before, so the date filter cannot constrain the LOD calculation. C describes the opposite of reality; visible rows being removed from the view does not strip them from a FIXED result, because FIXED never depended on the view's row context in the first place. D is simply false — FIXED expressions work perfectly alongside dimension filters; the two coexist by design, they just operate at different stages. As a study tip, memorize Tableau's filter order: Extract filters → Data source filters → Context filters → FIXED LODs → Dimension filters → INCLUDE/EXCLUDE LODs → Table calculations. Questions about unexpected LOD values almost always hinge on where in this chain something falls.

Question 8

A workbook uses FIXED:SUM([Sales]){ FIXED : SUM([Sales]) } as an overall sales benchmark. A data source filter removes returned orders, and an ordinary Sub-Category dimension filter keeps only Chairs.

Which records normally contribute to the benchmark?

  1. All orders, including returned orders and non-Chairs orders, because a dimensionless FIXED expression ignores every filter.
  2. Only non-returned Chairs orders, because both filters are evaluated before every FIXED expression.
  3. Only returned non-Chairs orders, because FIXED evaluates records excluded from the visible worksheet.
  4. All non-returned orders across sub-categories, because the source filter applies before FIXED but the ordinary dimension filter does not. (correct answer)
Explanation: Whenever you see a question involving FIXED Level of Detail (LOD) expressions in Tableau, the key concept to master is filter order of operations. Tableau evaluates filters in this sequence: Extract Filters → Data Source Filters → Context Filters → Fixed LOD expressions → Dimension Filters → Measure Filters. This hierarchy determines exactly which records any given calculation can "see." Because { FIXED : SUM([Sales]) } has no dimension specified, it aggregates across the entire dataset — but "entire" is relative to what has already been filtered upstream. Data source filters sit above FIXED LODs in the evaluation order, so they are applied first. This means returned orders, which are removed by the data source filter, never enter the calculation at all. However, ordinary dimension filters (like the Sub-Category filter keeping only Chairs) are evaluated after FIXED expressions. That dimension filter affects what rows appear on the worksheet, but it cannot reach back and trim the records the LOD already aggregated. So the benchmark captures all non-returned orders across every sub-category — exactly what D describes. A is wrong because it overstates FIXED's immunity. FIXED does not ignore data source filters — those filters eliminate records before FIXED ever runs. B is wrong because it treats both filters as if they operate at the same level, which they don't; the dimension filter cannot affect the FIXED calculation. C describes a completely backwards logic — FIXED doesn't seek out excluded records; it simply works with whatever the data source filter left behind. A practical tip: memorize the filter order as a stack — data source filters are "upstream" of FIXED, while dimension filters are "downstream." When in doubt, ask yourself where in that stack each filter lives.

Question 9

A worksheet contains Region in the view but does not contain Category. With no filters applied, an analyst creates EXCLUDE[Category]:SUM([Sales]){ EXCLUDE [Category] : SUM([Sales]) }.

How will this expression differ from the ordinary SUM([Sales])SUM([Sales]) at the Region level?

  1. It will return one total per category because EXCLUDE introduces the named dimension when it is absent.
  2. It will return the overall company total because every EXCLUDE expression removes all view dimensions.
  3. It will return the same regional totals because Category is not part of the view's level of detail. (correct answer)
  4. It will return null because an excluded dimension must appear in the view before the calculation is valid.
Explanation: Whenever you see a question about LOD expressions, the key question to ask is: does the dimension I'm excluding actually participate in the current view? That context determines everything about how the expression behaves. EXCLUDE\text{EXCLUDE} LOD expressions work by computing an aggregate at a coarser granularity than the view — they strip a named dimension out of the view's level of detail before aggregating. But here's the critical insight: if that dimension isn't in the view to begin with, there's nothing to remove. The calculation simply evaluates at whatever level of detail the view already uses — in this case, Region. The result is identical to a plain SUM([Sales])SUM([Sales]) broken out by Region. That confirms C as correct. Because Category was never part of the view's level of detail, the EXCLUDE [Category]\text{EXCLUDE [Category]} instruction has no effect, and you get the same regional totals you'd see with an ordinary SUM([Sales])SUM([Sales]). A is backwards — EXCLUDE\text{EXCLUDE} never introduces a dimension that's absent. It can only remove dimensions that are present. B reflects a common overgeneralization; EXCLUDE\text{EXCLUDE} does not remove all view dimensions, only the ones explicitly named. The remaining view dimensions (Region, here) still define the partition. D describes behavior that doesn't exist in Tableau — there's no validation error or null result when an excluded dimension is absent from the view; the expression simply resolves without effect. As a study tip: always map out which dimensions are actually in the view before reasoning about any LOD expression. The view's granularity is the anchor — LODs adjust relative to it.

Question 10

An analyst creates FIXED[Region]:SUM([Sales]){ FIXED [Region] : SUM([Sales]) }. A worksheet initially shows Region only. The analyst then adds Category to the view and displays the LOD result using MINMIN for each Region-Category mark.

How should the displayed LOD values change after Category is added?

  1. They should be divided among the categories because Category makes each regional mark more granular.
  2. They should become category totals because dimensions in the view override dimensions declared in FIXED.
  3. They should remain the same regional total on every category mark within the same region. (correct answer)
  4. They should become overall totals because adding Category causes Region to be excluded from the expression.
Explanation: Whenever you see a question involving FIXED\text{FIXED} LOD expressions, the core concept to internalize is this: FIXED\text{FIXED} ignores the view's level of detail entirely. It computes at exactly the dimension(s) you declare — nothing more, nothing less. Here, {FIXED [Region]:SUM([Sales])}\{ \text{FIXED } [\text{Region}] : \text{SUM}([\text{Sales}]) \} locks its computation to the Region grain. When you initially display only Region, each mark shows the correct regional total. When you add Category to the view, Tableau now renders one mark per Region-Category combination — but the LOD expression doesn't care. It still returns the same regional total it already computed. Using MINMIN to aggregate the LOD result per mark simply surfaces that single regional value, which is identical across every Category within the same Region. So C is correct: every Category mark inside a given Region displays the same regional total. Choice A is wrong because it confuses FIXED\text{FIXED} with INCLUDE\text{INCLUDE}. INCLUDE\text{INCLUDE} would incorporate Category into the computation, effectively splitting values across categories. FIXED\text{FIXED} does not do this. Choice B describes behavior that applies to dimension filters or context, not to dimensions added to the view. Dimensions in the view do not override or redefine what FIXED\text{FIXED} computes. Choice D confuses FIXED\text{FIXED} with EXCLUDE\text{EXCLUDE}. EXCLUDE\text{EXCLUDE} removes a dimension from the view's grain; adding Category to the view doesn't cause Region to disappear from the expression. Your study tip: memorize the hierarchy — FIXED\text{FIXED} ignores the view, INCLUDE\text{INCLUDE} adds to it, EXCLUDE\text{EXCLUDE} subtracts from it. That single distinction resolves most LOD questions on the exam.

Question 11

A worksheet shows sales by Region and Category. In the East region, Furniture sales are 100100 and Technology sales are 300300. The analyst defines the denominator as FIXED[Region]:SUM([Sales]){ FIXED [Region] : SUM([Sales]) } and calculates each category's share of regional sales. The analyst then applies Furniture as an ordinary dimension filter, not a context filter.

What percentage will the filtered Furniture mark show for the East region, and why?

  1. 25%25\%, because the numerator is filtered to Furniture while the FIXED denominator still includes both East categories. (correct answer)
  2. 100%100\%, because the category filter is applied before both the numerator and the FIXED regional denominator.
  3. 33.3%33.3\%, because Tableau averages the filtered Furniture value with the unfiltered Technology value.
  4. 75%75\%, because the FIXED expression retains Technology sales as the numerator after Furniture is selected.
Explanation: Whenever you see a question involving FIXED level-of-detail (LOD) expressions and filters, your first instinct should be to ask: at what point in Tableau's order of operations does each filter apply? This ordering is what makes LOD expressions powerful — and tricky. Here's the key rule: ordinary dimension filters apply after FIXED LOD expressions are computed. That means the FIXED denominator {FIXED [Region]:SUM([Sales])}\{ \text{FIXED [Region]} : \text{SUM([Sales])} \} locks in the East region total as 100+300=400100 + 300 = 400 before Tableau even considers the Furniture filter. When the filter runs, it removes Technology from the view, so the numerator becomes 100100 (Furniture only). The resulting share is 100400=25%\frac{100}{400} = 25\%. That confirms A is correct — the numerator is filtered while the denominator is protected by the FIXED expression. B is wrong because it reverses the order of operations. Ordinary filters do not apply before FIXED LODs — only context filters do. If the analyst had promoted the filter to a context filter, the denominator would recalculate to 100100 and the result would be 100%100\%. C describes behavior that doesn't exist in Tableau; the tool doesn't average filtered and unfiltered values together. D mischaracterizes how FIXED works — Technology sales are excluded from the numerator by the filter, not retained in it. Your study tip: remember the phrase "FIXED survives ordinary filters." If a question wants the LOD to respect a filter, look for context filters or INCLUDE/EXCLUDE LODs instead.

Question 12

An analyst must calculate each customer's total sales and use that value to classify the customer into a segment. The classification must remain valid even when the worksheet is rearranged from Region by Month to Category by Quarter.

Why is an LOD expression more appropriate than a table calculation for the customer total?

  1. An LOD expression establishes customer-level aggregation independently of the worksheet layout, while a table calculation depends on displayed marks and addressing settings that change when the view is rearranged. (correct answer)
  2. An LOD expression always runs after every filter type in Tableau's order of operations, while a table calculation always runs before any worksheet filter, making the LOD result more stable.
  3. An LOD expression automatically generates rows for customers missing from the current view, while a table calculation skips customers whose sales are null and would produce an incomplete classification.
  4. An LOD expression writes customer totals permanently to the data source so they persist across sessions, while a table calculation recomputes values only at extraction time and may become stale.
Explanation: When a question asks you to compare LOD expressions and table calculations, the central concept to focus on is scope of computation: where does Tableau evaluate the formula, and what determines the "universe" of data it sees? LOD (Level of Detail) expressions like { FIXED [Customer] : SUM([Sales]) } are resolved during the query phase, before Tableau renders any marks. This means the customer total is computed against the underlying data, completely independent of how dimensions are arranged on Rows, Columns, or any shelves. Whether your view is organized by Region/Month or Category/Quarter, that fixed customer total stays identical — which is exactly what the analyst needs for stable classification. Answer A captures this precisely and is correct. The distractors each introduce a plausible-sounding but false claim. B reverses the actual order of operations: LOD expressions using FIXED run before dimension filters, not after every filter type. Context filters and data source filters interact with LODs differently, so saying LODs "always run after every filter" is simply wrong. C invents a behavior that doesn't exist — LOD expressions don't automatically generate rows for missing customers; they aggregate the customers present in the data source. A table calculation skipping nulls is also not the defining reason to choose LODs. D is completely fabricated: LOD expressions do not write anything permanently to the data source. They are in-memory query constructs, not persistent storage mechanisms. A reliable study tip: whenever a question mentions that a calculation must survive view rearrangement, think LOD — it computes at the data level, while table calculations compute at the view level.

Question 13

A worksheet shows one mark for each combination of Year and Month. The analyst wants every monthly mark to display its year's total sales. The result should respond to an ordinary Region dimension filter, and Region is not displayed in the view.

Which LOD expression best meets these requirements?

  1. FIXED[Year]:SUM([Sales]){ FIXED [Year] : SUM([Sales]) }, because FIXED expressions respond to ordinary dimension filters regardless of filter order.
  2. INCLUDE[Year]:SUM([Sales]){ INCLUDE [Year] : SUM([Sales]) }, because INCLUDE adds Year to the calculation's granularity, removing Month from the yearly total.
  3. EXCLUDE[Month]:SUM([Sales]){ EXCLUDE [Month] : SUM([Sales]) }, because it removes Month from the view's granularity after ordinary dimension filtering, producing a yearly total that responds to the Region filter. (correct answer)
  4. FIXED[Month]:SUM([Sales]){ FIXED [Month] : SUM([Sales]) }, because fixing by Month and then aggregating rolls the monthly values up to the Year level.
Explanation: When working with LOD expressions in Tableau, the critical question is always: which filters does this expression respect, and at what granularity does it compute? Here, you need a yearly total that (1) ignores Month and (2) still responds to a Region dimension filter. EXCLUDE[Month]:SUM([Sales]){ EXCLUDE [Month] : SUM([Sales]) } does exactly this. EXCLUDE expressions compute after ordinary dimension filters are applied, so a Region filter will correctly narrow the data before the aggregation runs. By removing Month from the view's granularity, the expression aggregates Sales across the full year — giving every monthly mark its year's total. This makes C the correct answer. Choice A is the most tempting trap. FIXED expressions do not respect ordinary dimension filters — they sit above them in Tableau's order of operations. A Region filter would be silently ignored unless you promoted it to a context filter, which the question does not mention. So FIXED[Year]:SUM([Sales]){ FIXED [Year] : SUM([Sales]) } would produce incorrect totals when Region is filtered. Choice B misreads what INCLUDE does. INCLUDE[Year]:SUM([Sales]){ INCLUDE [Year] : SUM([Sales]) } adds Year to the existing granularity (Year + Month), which doesn't remove Month — it just makes the dimension list redundant. You get a mark-level total, not a yearly total. Choice D is nonsensical. FIXED[Month]:SUM([Sales]){ FIXED [Month] : SUM([Sales]) } computes a total per Month across all years, which is neither a yearly total nor Region-filter-aware. Study tip: Memorize the filter-order hierarchy — FIXED ignores dimension filters, while INCLUDE and EXCLUDE respect them. On LOD questions, always ask "does this expression need to respond to a filter?" before choosing FIXED.

Question 14

Customer A has two orders of 100100 each. Customer B has one order of 400400. A worksheet contains no dimensions, and the analyst wants the average total sales per customer rather than the average sales per order.

Which calculation most directly produces the intended value of 300300?

  1. AVG([Sales])AVG([Sales]), because averaging the three order rows first preserves each customer's contribution.
  2. AVG(INCLUDE[Customer]:SUM([Sales]))AVG({ INCLUDE [Customer] : SUM([Sales]) }), because customer totals are formed before they are averaged. (correct answer)
  3. FIXED:AVG([Sales]){ FIXED : AVG([Sales]) }, because fixing the calculation globally converts order-level values into customer totals.
  4. EXCLUDE[Customer]:SUM([Sales]){ EXCLUDE [Customer] : SUM([Sales]) }, because excluding Customer assigns equal weight to every customer.
Explanation: When a worksheet has no dimensions, Tableau aggregates all rows together — so a simple aggregate like AVG([Sales])AVG([Sales]) operates at the order level, not the customer level. The key question to ask yourself is: at what granularity do I need to aggregate before averaging? Here, you want customer totals first, then average those totals. Option B, AVG({INCLUDE[Customer]:SUM([Sales])})AVG(\{ INCLUDE [Customer] : SUM([Sales]) \}), does exactly that. The INCLUDE LOD expression computes SUM([Sales])SUM([Sales]) per customer — giving Customer A 200200 and Customer B 400400 — and then the outer AVGAVG averages those two values: (200+400)/2=300(200 + 400) / 2 = 300. The LOD forces the inner calculation to a finer grain before the outer aggregation runs. Option A is the most tempting trap. AVG([Sales])AVG([Sales]) averages all three order rows equally: (100+100+400)/3≈200(100 + 100 + 400) / 3 \approx 200, not 300300. This weights by orders, not customers. Option C misunderstands FIXED. {FIXED:AVG([Sales])}\{ FIXED : AVG([Sales]) \} fixes the calculation at the highest level with no dimensions, so it still averages all order rows globally — same flaw as A, just wrapped in an LOD. Option D, {EXCLUDE[Customer]:SUM([Sales])}\{ EXCLUDE [Customer] : SUM([Sales]) \}, sums all sales regardless of customer, returning a grand total of 600600 — a single number, not a per-customer average. Study tip: Whenever you need to "average a sum," reach for an LOD expression to pre-aggregate at the right granularity. The pattern AVG({INCLUDE[Dimension]:SUM([Measure])})AVG(\{ INCLUDE [Dimension] : SUM([Measure]) \}) is a classic Tableau technique worth memorizing.

Question 15

Which requirement most directly calls for an LOD expression rather than a standard aggregation or table calculation?

  1. Display total sales for each region when Region already defines the marks in the worksheet.
  2. Display a running sum across months using the visible chronological order of the marks.
  3. Display the distinct customer count for each category when Category defines the worksheet marks.
  4. Compare every order mark with its customer's lifetime average when Customer is absent from the view. (correct answer)
Explanation: When deciding between a standard aggregation, table calculation, or LOD (Level of Detail) expression, ask yourself one key question: does the calculation require a granularity that the current view cannot provide on its own? LOD expressions exist specifically to anchor a computation at a dimension level independent of what's drawn on the canvas. Option D is the scenario that demands an LOD. You need each order mark to carry its customer's lifetime average purchase value — but Customer isn't in the view, so Tableau has no natural way to compute that per-customer aggregate. A FIXED LOD like { FIXED [Customer] : AVG([Sales]) } calculates at the customer grain regardless of view structure, then brings that value into the order-level marks for comparison. No standard aggregation or table calculation can reference a dimension absent from the view this cleanly. Option A is a trap: when Region already defines the marks, SUM([Sales]) aggregates correctly at that level automatically. No LOD needed. Option B describes a running total across an ordered sequence — that's a classic table calculation (Running Sum), which operates on existing marks in display order. Option C mirrors the logic of A: when Category defines the marks, COUNTD([Customer]) already computes at the category grain. Adding an LOD there would be redundant. The study tip to remember: LOD expressions solve the granularity mismatch problem. If the dimension driving your calculation is missing from the view, that's your signal to reach for FIXED, INCLUDE, or EXCLUDE. If the dimension is already in the view, a standard aggregation likely suffices; if you need ordered, view-dependent math, use a table calculation.