Tableau Quiz: Filters And Filter Order
10 questions · exam conditions
0:00
Filters And Filter OrderQuestion 1 of 10

A worksheet shows customers ranked by total sales. A Top filter on Customer Name keeps the top 55 customers by SUM(Sales). The worksheet also has a standard Region filter. When a user selects West, only 22 customers appear because only 22 of the overall top 55 customers are in West.

Which change makes the worksheet display the top 55 customers within the selected region?

Add the Region filter to context so the Top filter evaluates only records from the selected region.
Convert the Region filter to a measure filter so it evaluates after customer sales have been aggregated.
Configure the Region filter to show only relevant values so the Top filter uses the selected region.
Add the Customer Name filter to context so the Region filter evaluates only the current top customers.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Filters And Filter Order

Practice Filters And Filter Order 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 Filters And Filter Order, 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 shows customers ranked by total sales. A Top filter on Customer Name keeps the top 55 customers by SUM(Sales). The worksheet also has a standard Region filter. When a user selects West, only 22 customers appear because only 22 of the overall top 55 customers are in West.

Which change makes the worksheet display the top 55 customers within the selected region?

  1. Add the Region filter to context so the Top filter evaluates only records from the selected region. (correct answer)
  2. Convert the Region filter to a measure filter so it evaluates after customer sales have been aggregated.
  3. Configure the Region filter to show only relevant values so the Top filter uses the selected region.
  4. Add the Customer Name filter to context so the Region filter evaluates only the current top customers.
Explanation: Whenever you see a question about Tableau filters producing unexpected results, think about filter order of operations. By default, Tableau evaluates filters in this sequence: Extract → Data Source → Context → Top N / Condition → Dimension → Measure. The key insight is that Top N filters run before standard dimension filters, which is exactly why this scenario breaks. Here's what's happening: the Top filter first identifies the 5 highest-spending customers across all regions, then the Region filter trims that list down to only those who happen to be in West — leaving you with just 2. To fix this, you need the Region filter to run first, so the Top filter only "sees" West customers when it calculates the top 5. That's precisely what adding the Region filter to context accomplishes. Context filters execute before Top N filters, so Tableau first isolates West records, then finds the top 5 within that subset. Option A is correct. Option B is wrong because converting a filter to a measure filter changes when it runs relative to aggregation, not relative to the Top N filter — it doesn't solve the ordering problem described. Option C is wrong because "Show only relevant values" is a dropdown display setting that controls which values appear in the filter card UI; it has no effect on filter evaluation order or Top N logic. Option D is wrong because adding Customer Name to context would place the customer list before the Region filter, which is the opposite of what you need — it doesn't give the Top filter a region-scoped dataset. A reliable study tip: whenever a Top N filter is returning results from the wrong scope, your first instinct should be to push the scoping filter into context.

Question 2

A worksheet displays each category's percent of total sales. The denominator must continue to include every category, but the final view should display only categories whose computed percent of total exceeds 10%10\%.

Which filtering approach satisfies both requirements?

  1. Apply a data source filter to Category before Tableau calculates each category's percentage of total.
  2. Apply an ordinary Category dimension filter before calculating percent of total for the remaining categories.
  3. Make Category a context filter and retain only categories whose visible percentages exceed the threshold.
  4. Filter the percent-of-total table calculation, allowing Tableau to compute all percentages before hiding marks. (correct answer)
Explanation: Whenever Tableau questions mention "percent of total" alongside filtering, the key tension is when filtering occurs relative to the table calculation. Tableau's order of operations places dimension filters before table calculations, which means filtering too early changes the denominator of your percentage — exactly what this question forbids. The only approach that lets Tableau compute every category's share of the full total first, then hide marks afterward, is filtering on the table calculation result itself. When you drag the percent-of-total pill to the Filters shelf, Tableau evaluates that filter after the calculation completes. Every category contributes to the 100%100\% denominator, and only the display is trimmed to categories exceeding 10%10\%. That's why D is correct. A fails immediately: a data source filter removes rows before Tableau even builds the view, so the denominator shrinks to include only the surviving categories, corrupting every percentage. B makes the same logical mistake at a different stage. An ordinary dimension filter on Category executes before table calculations, so the percent of total recalculates over the filtered subset — the denominator no longer represents all categories. C is a common trap. Context filters are often presented as a "deeper" filter, but they still execute before table calculations. Making Category a context filter removes non-qualifying categories from the partition the table calculation sees, again altering the denominator. Study tip: Memorize Tableau's order of operations — Extract → Data Source Filters → Context Filters → Dimension Filters → Measure Filters → Table Calculations. Any filter placed before table calculations in that chain will corrupt a percent-of-total. When the denominator must stay fixed, filter on the calculated field itself.

Question 3

A worksheet has two context filters: Region is restricted to East, and Segment is restricted to Consumer. A Product Name filter then keeps the top 33 products by SUM(Sales).

From which records does Tableau determine the top 33 products?

  1. Records satisfying whichever context filter was most recently added to the Filters shelf.
  2. Records satisfying East or Consumer, because multiple context filters are combined as alternatives.
  3. All records, because Top filters are calculated before context filters in the order of operations.
  4. Records satisfying both East and Consumer, because multiple context filters form an intersected context. (correct answer)
Explanation: When you see a question about filter order of operations in Tableau, the key concept to anchor on is how context filters work together. A context filter creates a temporary, restricted dataset that all subsequent filters operate against. When you add multiple context filters, they don't work independently — they compound. Each context filter further narrows the same working dataset, so the result is the intersection of all context filter conditions. In this scenario, the first context filter restricts records to Region = East, and the second context filter then restricts that already-filtered set to Segment = Consumer. By the time Tableau evaluates the Top N filter on Product Name, it's working against only records where both conditions are true simultaneously: East and Consumer. From that intersected pool, Tableau identifies the top 33 products by SUM(Sales). That makes D the correct answer. A is wrong because context filters don't have a recency-based priority — all active context filters apply together regardless of the order they were added. B describes a union (OR logic), but context filters use AND logic by default; each one narrows the dataset further rather than expanding it with alternatives. C gets the order of operations exactly backwards — Top N filters are downstream from context filters, not upstream, meaning they are calculated after the context has already been established. A useful rule of thumb: think of context filters as a funnel. Each one you add makes the opening smaller. Whatever comes out the bottom — that's the data your downstream filters, including Top N, actually see.

Question 4

A worksheet has two ordinary filters. Region is used as a blue discrete dimension filter, and SUM(Sales) is used as a green continuous measure filter. Neither filter is a context, data source, or table calculation filter.

Which statement correctly describes their conceptual evaluation order?

  1. The green SUM(Sales) filter is evaluated before the blue Region filter because continuous filters have priority.
  2. The Region dimension filter is evaluated before the SUM(Sales) measure filter, regardless of their pill colors. (correct answer)
  3. Both filters are evaluated at the measure-filter stage because green pills always represent measures.
  4. Their order is determined by their vertical positions on the Filters shelf rather than their field roles.
Explanation: Whenever you see a question about Tableau's filter evaluation order, anchor yourself to one core principle: Tableau processes filters in a fixed conceptual sequence based on what type of field is being filtered, not visual styling or shelf position. The standard order is: Extract filters → Data Source filters → Context filters → Dimension filters → Measure filters → Table Calculation filters. Dimension filters (which filter on discrete categorical fields like Region) are always evaluated before measure filters (which filter on aggregated values like SUM(Sales)). This makes logical sense — Tableau needs to know which rows belong to which dimension members before it can aggregate and filter on those measures. So B is correct: Region, as a dimension filter, is evaluated first, and SUM(Sales), as a measure filter, is evaluated second, regardless of pill color. Answer A is wrong because "continuous" vs. "discrete" (green vs. blue) does not determine evaluation priority — that distinction relates to how values are visualized, not when they're filtered. A green continuous field still follows the same filter-order rules as its field type dictates. Answer C is wrong on two counts: not all green pills are measures (dates and numeric dimensions can also be continuous/green), and the filter stage is determined by field role, not pill color. Answer D is wrong because Tableau's filter evaluation order is governed by the filter hierarchy described above — vertical position on the Filters shelf has no effect on when filters are applied. Your study tip: memorize the filter order acronym E-DS-C-D-M-TC (Extract, Data Source, Context, Dimension, Measure, Table Calculation). On exam questions involving filter interactions, this sequence will reliably guide you to the right answer.

Question 5

A worksheet has ordinary State and City dimension filters. The City filter is configured to show only relevant values. After a user selects California in State, the City control lists only cities associated with California.

What does this behavior imply about filtering and interactivity?

  1. The State filter has automatically become a context filter and now executes before every other dimension filter.
  2. The control's available City values are restricted interactively, while the final data still satisfies both ordinary dimension filters. (correct answer)
  3. The City filter has become a measure filter because its displayed domain depends on the selected State.
  4. The State selection is merely cosmetic until the user also chooses one of the remaining City values.
Explanation: When working with Tableau filters, it helps to distinguish between how values appear in a filter control and how the underlying query executes. These are two separate mechanisms, and confusing them is exactly what this question tests. The scenario describes a City filter set to "Only Relevant Values." This is a display-level setting — it narrows which cities appear in the dropdown based on what the State filter has selected. Crucially, this does not change the filter type or execution order. Both State and City remain ordinary dimension filters, and when a view is rendered, Tableau applies both simultaneously to the data. The City control simply hides irrelevant options to improve usability, while the final result still reflects both filters working together. That's precisely what B captures: interactive restriction of the displayed domain, with the underlying data still satisfying both filters. A is wrong because "Only Relevant Values" does not promote the State filter to a context filter. Context filters are explicitly configured by right-clicking and selecting "Add to Context" — they change the query execution pipeline. Relevant values filtering is purely a UI convenience. C is wrong because the City filter's classification (dimension vs. measure) is determined by the field type, not by whether its displayed values depend on another filter. It remains a dimension filter regardless. D is wrong because the State selection is not cosmetic — it actively filters the data in the view. Choosing California immediately restricts the rows Tableau queries. Study tip: On Tableau questions, always ask yourself whether a behavior affects the query pipeline or just the control's appearance. "Only Relevant Values" touches the display layer only — keep that boundary clear.

Question 6

A worksheet first uses a Top filter to keep the top 55 products by SUM(Sales). It also has a measure filter requiring SUM(Profit) to be greater than zero. Two of the top 55 products by sales have negative profit.

Assuming no other filters affect the view, what result should be expected?

  1. All profitable products remain because the measure filter executes before and overrides the Top product filter.
  2. Five products remain because Tableau replaces the two unprofitable products with the next products by sales.
  3. Only 33 products remain because the measure filter removes two products without rerunning or backfilling the Top filter. (correct answer)
  4. No products remain because a positive-profit measure filter conflicts with a Top filter based on sales.
Explanation: Whenever you see a question combining a Top N filter with a measure filter in Tableau, your first instinct should be to recall Tableau's order of operations (also called the filter pipeline). Filters execute in a fixed sequence: Top N filters run first, and then measure filters (condition-based filters on aggregates) run afterward on the already-reduced dataset. Here's how the logic plays out in this scenario: Tableau first applies the Top filter, selecting the top 55 products by SUM(Sales). That gives you a pool of exactly 55 products. Next, the measure filter — requiring SUM(Profit) > 0 — runs against those 55 products and eliminates the two with negative profit. Crucially, Tableau does not loop back and refill the list with replacements. The Top filter already completed its job, and the pipeline moves forward. You're left with 5−2=35 - 2 = 3 products, making C the correct answer. A is wrong because the measure filter does not execute before the Top filter — it executes after. There is no "override" mechanism working in reverse here. B describes a backfilling behavior that Tableau simply does not perform; once the Top filter has run, its result is locked, and no substitution occurs. D fabricates a conflict that doesn't exist — filters don't "cancel each other out" just because they reference different measures; they simply execute sequentially and independently. A useful rule of thumb: memorize Tableau's filter order as Extract → Data Source → Context → Top/Sets → Dimension → Measure → Table Calc. On exam questions mixing filter types, always ask yourself which filter runs first and whether the pipeline cycles back — it never does.

Question 7

A worksheet uses the calculation { FIXED [Customer Name] : SUM([Sales]) } to display customer sales. Region is an ordinary dimension filter. Users report that changing Region does not change the calculated customer-sales values.

Without changing the calculation, which action will make the selected Region affect the FIXED result?

  1. Add the Region filter to context so it is applied before the FIXED level-of-detail calculation. (correct answer)
  2. Place Region before Customer Name on the Filters shelf so Tableau evaluates it first.
  3. Set the Region control to show only relevant values so FIXED uses the selected records.
  4. Change the Region pill from discrete to continuous so it precedes the FIXED calculation.
Explanation: Whenever you see a question about FIXED level-of-detail (LOD) expressions in Tableau, you need to think about the order of operations. Tableau evaluates filters in a specific sequence: context filters → FIXED LODs → dimension filters → measure filters. This hierarchy is the key to understanding why Region isn't working. Because { FIXED [Customer Name] : SUM([Sales]) } is a FIXED LOD, it executes after context filters but before ordinary dimension filters. This means a Region filter sitting on the Filters shelf as a normal dimension filter has no effect on the LOD — the calculation has already locked in its values for every customer across all regions before Region gets a chance to filter the data. The fix is A: promoting Region to a context filter forces Tableau to apply it first, narrowing the underlying data before the FIXED LOD computes. Now the calculation only sees records within the selected Region, so customer sales values update as expected. B is wrong because filter shelf order doesn't change when Tableau evaluates filters relative to LOD calculations — only context promotion does that. Reordering pills on the shelf has no effect on the execution sequence. C is wrong because "show only relevant values" controls what appears in the filter dropdown UI — it's a display setting, not a data processing instruction, and has no impact on LOD evaluation. D is wrong because discrete vs. continuous is a visual/formatting property controlling how pills are displayed. It has absolutely no bearing on calculation order. Your study tip: memorize Tableau's filter order of operations — context → FIXED → dimension — and recognize that "promote to context" is almost always the solution when a FIXED LOD ignores a dimension filter.

Question 8

A data source filter limits records to the current fiscal year. A worksheet also has an ordinary Region dimension filter and uses { FIXED [Customer Name] : SUM([Sales]) }. A user selects West in the Region filter.

What sales records contribute to each customer's FIXED value?

  1. All-year records from West only, because the ordinary Region filter precedes FIXED while the data source filter follows it.
  2. Current-fiscal-year records from West only, because both visible filters are evaluated before the FIXED expression.
  3. Current-fiscal-year records from all regions, because the data source filter precedes FIXED but the ordinary Region filter follows it. (correct answer)
  4. All-year records from all regions, because FIXED expressions ignore both data source and ordinary dimension filters.
Explanation: Whenever you see a question involving LOD expressions in Tableau, your first instinct should be to recall the order of operations: Data Source Filters → Extract Filters → FIXED LODs → Dimension Filters (Context, then ordinary) → Measure Filters. This hierarchy determines exactly which records each filter type "sees." Because data source filters sit above FIXED LODs in the order of operations, they restrict the underlying data before the FIXED expression ever runs. In this scenario, the data source filter limits records to the current fiscal year — so { FIXED [Customer Name] : SUM([Sales]) } only has access to current-fiscal-year records. Ordinary dimension filters, however, sit below FIXED LODs, meaning the Region filter is applied after the FIXED value is already computed. The FIXED expression therefore aggregates across all regions within the fiscal year, not just West. The Region filter then narrows which customers are displayed, but doesn't change what was computed. This makes C the correct answer: current-fiscal-year records from all regions feed the FIXED calculation. A is wrong because it inverts both relationships — ordinary filters do not precede FIXED, and data source filters do not follow it. B is wrong because it assumes the ordinary Region filter runs before the FIXED expression, which contradicts Tableau's order of operations; ordinary dimension filters come after FIXED. D is wrong because FIXED expressions do not ignore data source filters — that's a common misconception. Only context filters and ordinary dimension filters are bypassed by FIXED; data source filters always apply first. A handy study tip: memorize the phrase "Data Source → FIXED → Dimension" as your anchor. Any filter above FIXED restricts it; any filter below it is ignored by it.

Question 9

A Customer Name filter uses its Condition tab to retain customers whose SUM(Sales) is at least 10,00010{,}000. An ordinary Category filter is set to Furniture. Users expect customers to qualify based only on Furniture sales, but Tableau currently qualifies them using sales across all categories.

Which change will make the customer condition evaluate using Furniture records only?

  1. Add the Category filter to context so it restricts the data before the conditional customer filter. (correct answer)
  2. Add the conditional Customer Name filter to context so Category is evaluated before customer sales.
  3. Change Category to show only relevant values so the customer condition uses visible Furniture records.
  4. Move Category above Customer Name on the Filters shelf so it executes before the condition.
Explanation: Whenever you see a question about Tableau filters producing unexpected results, think about filter order of operations. By default, dimension filters and conditional filters operate on the full dataset independently — they don't automatically restrict each other unless you use context. Context filters run first, essentially creating a temporary filtered table that all subsequent filters evaluate against. When you add the Category filter to context (choice A), Tableau processes it before the conditional Customer Name filter. This means when Tableau calculates SUM(Sales) for each customer to check the $10,000\$10{,}000 threshold, it only sees Furniture records — exactly the behavior users expect. That's why A is correct. Choice B has the logic backwards. Adding the conditional Customer Name filter to context would force it to run first, meaning it still evaluates against all categories before Category is even applied. Context helps downstream filters, not the filter placed in context itself. Choice C — setting Category to show only "relevant values" — controls what appears in the filter dropdown for interactivity purposes. It affects the filter UI, not the underlying data that the customer condition evaluates. This is a common trap: "relevant values" is about display, not computation scope. Choice D is perhaps the most tempting distractor. Filter shelf order looks like execution order, but it isn't. Tableau doesn't process filters top-to-bottom on the shelf; it follows a fixed order of operations (context → sets → fixed LODs → dimension filters → measure filters). Rearranging the shelf changes nothing about when the condition runs. Study tip: Memorize Tableau's filter order of operations. "Context first" is one of the most frequently tested concepts — whenever a filter needs to restrict the data that another filter sees, context is the tool.

Question 10

A view contains Customer Name and SUM(Sales). Customer A has two transaction rows of 6060 each, while Customer B has one transaction row of 9090.

Which filter retains Customer A and excludes Customer B based on total sales of at least 100100?

  1. Apply a measure filter requiring SUM(Sales) to be at least 100100 in the current view. (correct answer)
  2. Apply a row-level Boolean dimension filter requiring each Sales value to be at least 100100.
  3. Apply a dimension filter that retains the individual Sales values 6060 and 9090.
  4. Apply a measure filter requiring AVG(Sales) to be at least 100100 in the current view.
Explanation: When filtering in Tableau, you need to distinguish between row-level filters (which evaluate each individual row of data) and measure filters (which evaluate aggregated values after grouping). This question tests exactly that distinction. Customer A has two rows of $60\$60 each, so their total is 60+60=$12060 + 60 = \$120, which meets the ≥$100\geq \$100 threshold. Customer B has one row of $90\$90, which falls short. To make this determination, Tableau must first aggregate the data by customer, then apply the filter — that's precisely what a measure filter on SUM(Sales) does. Choice A is correct because it filters on the aggregated SUM(Sales)\text{SUM(Sales)} per customer, keeping Customer A ($120\$120) and removing Customer B ($90\$90). Choice B fails because a row-level Boolean filter evaluates each transaction individually. Neither of Customer A's $60\$60 rows meets the $100\$100 threshold, so Customer A would actually be excluded — the opposite of the desired result. Choice C describes a dimension filter on individual Sales values, which doesn't aggregate anything and would simply show or hide specific raw values, not customer totals. Choice D uses AVG(Sales) instead of SUM. Customer A's average is 60+602=$60\frac{60+60}{2} = \$60, which fails the $100\$100 threshold — so this filter would incorrectly exclude Customer A. A useful rule of thumb: whenever a question asks you to filter based on a total or summary across rows, reach for a measure filter on an aggregate, not a row-level filter.