Tableau Quiz: Conditional Logic In Calculations
10 questions · exam conditions
0:00
Conditional Logic In CalculationsQuestion 1 of 10

A worksheet classifies orders with the following calculated field:

IF [Sales] >= 1000 THEN "Large" ELSEIF [Sales] >= 500 AND [Profit] < 0 THEN "Review" ELSE "Standard" END

An order has Sales of 12001200 and Profit of −150-150.

What value does the calculated field return for this order?

"Large", because Tableau returns the result for the first condition that evaluates to true.
"Review", because the order satisfies both the sales threshold and the negative-profit test.
"Standard", because two conditions are true and therefore neither classification is exclusive.
A null value, because overlapping true conditions make the conditional calculation ambiguous.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Conditional Logic In Calculations

Practice Conditional Logic In Calculations 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 Conditional Logic In Calculations, 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 classifies orders with the following calculated field:

IF [Sales] >= 1000 THEN "Large" ELSEIF [Sales] >= 500 AND [Profit] < 0 THEN "Review" ELSE "Standard" END

An order has Sales of 12001200 and Profit of −150-150.

What value does the calculated field return for this order?

  1. "Large", because Tableau returns the result for the first condition that evaluates to true. (correct answer)
  2. "Review", because the order satisfies both the sales threshold and the negative-profit test.
  3. "Standard", because two conditions are true and therefore neither classification is exclusive.
  4. A null value, because overlapping true conditions make the conditional calculation ambiguous.
Explanation: When you see an IF / ELSEIF / ELSE calculated field in Tableau, the key concept to keep in mind is short-circuit evaluation: Tableau tests each condition in the order it's written and immediately returns the result of the first condition that evaluates to true — it never checks the remaining branches. For this order (Sales = 12001200, Profit = −150-150), Tableau evaluates the first condition: [Sales] >= 1000. Since 1200≥10001200 \geq 1000 is true, Tableau returns "Large" right there and stops. The ELSEIF branch is never even reached, making A the correct answer. Choice B is the most tempting trap. Yes, this order does satisfy both [Sales] >= 500 and [Profit] < 0, so the "Review" condition is logically true — but it's never evaluated because Tableau already exited the logic at the first branch. Confusing "is the condition satisfiable?" with "will Tableau reach that condition?" is the classic mistake here. Choice C introduces a false rule: there is no such thing as mutual exclusivity canceling out in Tableau's conditional logic. Multiple true conditions don't neutralize each other. Choice D is similarly invented. Overlapping conditions do not produce a null — Tableau's IF/ELSEIF structure is unambiguous by design, always resolving to exactly one branch. Study tip: Whenever you see IF / ELSEIF in Tableau, mentally trace the logic from top to bottom and stop the moment you hit a true condition. The order of your branches matters enormously — structure your logic from most specific (or highest priority) to least specific.

Question 2

A data source has these three records: Online Sales of 100100, Store Sales of 200200, and Partner Sales of 300300. The following measure is placed in the view:

SUM( CASE [Channel] WHEN "Online" THEN [Sales] WHEN "Store" THEN [Sales] * 0.90 END )

What value does the measure return?

  1. 300300, because only the first matching WHEN branch contributes to the view.
  2. 580580, because the unmatched Partner row retains its original Sales value.
  3. 280280, because the unmatched Partner row returns null and is ignored by SUM. (correct answer)
  4. 600600, because CASE affects labels but does not modify measure values.
Explanation: When you see a CASE expression inside an aggregate like SUM, the key question to ask is: what does the expression return for rows that don't match any WHEN clause? Understanding that behavior is everything here. The CASE statement evaluates each row individually. For the Online row, it returns 100100. For the Store row, it returns 200×0.90=180200 \times 0.90 = 180. For the Partner row, neither WHEN condition matches, and there is no ELSE clause — so the expression returns NULL. SUM ignores NULL values entirely, meaning only 100+180=280100 + 180 = 280 contributes to the final result. That makes C correct. A is wrong because SUM doesn't stop at the first matching branch — it aggregates all rows. The "first matching" framing describes no real Tableau behavior; every row is evaluated independently. B reflects a common misconception: that an unmatched row "falls through" and contributes its original [Sales] value. It doesn't. Without an ELSE clause, an unmatched row yields NULL, not the underlying field value. If you wanted Partner Sales included, you'd need ELSE [Sales] explicitly. D is simply confused about what CASE does. CASE absolutely transforms the values being aggregated — it doesn't just relabel them. As a study tip, always mentally add an invisible ELSE NULL to any CASE expression that lacks one. That habit will help you trace exactly which rows contribute to any aggregate and which silently drop out.

Question 3

An analyst must label null Region values as "Unassigned", East and West as "Domestic", and every other non-null Region as "Other".

Which calculation reliably applies all three rules?

  1. CASE [Region] WHEN NULL THEN "Unassigned" WHEN "East" THEN "Domestic" WHEN "West" THEN "Domestic" ELSE "Other" END
  2. IF [Region] = NULL THEN "Unassigned" ELSEIF [Region] IN ("East", "West") THEN "Domestic" ELSE "Other" END
  3. IF ISNULL([Region]) THEN "Unassigned" ELSEIF [Region] = "East" OR [Region] = "West" THEN "Domestic" ELSE "Other" END (correct answer)
  4. IF ISNULL([Region]) THEN "Unassigned" ELSE CASE [Region] WHEN "East" THEN "Domestic" ELSE "Other" END END
Explanation: Handling nulls in Tableau calculations is a classic trap because null values behave differently depending on which function you use. Whenever a question asks you to categorize nulls alongside other specific values, your first instinct should be: how does this function actually detect null? The reliable approach in C works because ISNULL([Region]) is purpose-built to detect null values — it returns TRUE when the field is null, regardless of data type. From there, the ELSEIF chain checks for East or West explicitly, and the ELSE catches everything remaining non-null. All three business rules are covered cleanly and correctly. Answer A fails silently. CASE statements use equality comparisons internally, and in Tableau, NULL = NULL evaluates to null (not TRUE) — so WHEN NULL never matches. Null rows fall through to "Other" instead of "Unassigned", breaking the first rule entirely. Answer B has the same fundamental flaw. Writing [Region] = NULL inside an IF statement also uses equality comparison, which cannot match null. Tableau won't throw an error — it simply evaluates to null and skips that branch, so nulls again land in "Other". Answer D is partially correct — it uses ISNULL() properly — but it only handles East in the nested CASE, not West. West would fall into the inner ELSE "Other" branch, misclassifying it and violating the second rule. Study tip: On Tableau exams, always use ISNULL() or ZN() to test for null — never = NULL. Equality comparisons with null are a near-universal wrong-answer trap.

Question 4

An order should be flagged only when it is in the West region and it also has either Sales of at least 10001000 or High priority.

Which calculation implements the requirement without unintentionally flagging High-priority orders from other regions?

  1. IF [Region] = "West" AND [Sales] >= 1000 OR [Priority] = "High" THEN "Flag" ELSE "No Flag" END
  2. IF [Region] = "West" AND ([Sales] >= 1000 OR [Priority] = "High") THEN "Flag" ELSE "No Flag" END (correct answer)
  3. IF ([Region] = "West" AND [Sales] >= 1000) OR [Priority] = "High" THEN "Flag" ELSE "No Flag" END
  4. IF ([Region] = "West" OR [Sales] >= 1000) AND [Priority] = "High" THEN "Flag" ELSE "No Flag" END
Explanation: When a logical condition mixes both AND and OR operators, operator precedence determines how Tableau groups and evaluates them — and getting this wrong produces calculations that silently misbehave. In Tableau (as in most programming languages), AND binds more tightly than OR, meaning it evaluates first unless you use parentheses to override that order. The requirement has a specific structure: the Region gate must apply to both sub-conditions. In plain English: "West, AND THEN (Sales ≥ 1000 OR High priority)." Answer B captures this exactly — the parentheses force the OR to resolve first as a single unit, and then that unit is combined with the Region check via AND. An order only gets flagged if it's in the West and meets at least one of the two sales/priority conditions. Answer A looks almost identical to B but is missing the parentheses. Because AND evaluates before OR, Tableau reads it as (Region = "West" AND Sales >= 1000) OR Priority = "High" — which means any High-priority order, regardless of region, gets flagged. That's exactly the unintentional behavior the question warns against. Answer C makes the same logical mistake explicitly — it writes out the incorrect grouping with parentheses, flagging all High-priority orders from any region. Answer D restructures the conditions entirely, requiring High priority to be present in all cases, which contradicts the requirement that Sales ≥ 1000 alone (within the West) should trigger a flag. Study tip: Whenever you see both AND and OR in a Tableau condition, immediately ask yourself whether parentheses are needed to protect your OR groups — the absence of parentheses almost always hides a precedence bug.

Question 5

Customer C1 has two Returned order records. Customer C2 has one Completed record and one Returned record. Customer C3 has one Completed record. An analyst needs the number of distinct customers who have at least one Returned record.

Which Tableau calculation returns the required value of 22?

  1. COUNT(IF [Order Status] = "Returned" THEN [Customer ID] END)
  2. COUNTD(IF [Order Status] = "Returned" THEN [Customer ID] END) (correct answer)
  3. SUM(IF [Order Status] = "Returned" THEN 1 ELSE 0 END)
  4. IF [Order Status] = "Returned" THEN COUNTD([Customer ID]) ELSE 0 END
Explanation: When a question asks for distinct customers meeting a condition, you need two things working together: a filter that isolates the right rows, and a distinct count that avoids double-counting. This question tests whether you understand how COUNTD interacts with conditional logic in Tableau. The right approach is B. COUNTD(IF [Order Status] = "Returned" THEN [Customer ID] END) works by returning the Customer ID only when the status is "Returned" — and NULL otherwise. COUNTD then counts only the non-null, distinct values. C1 appears twice as "Returned," but COUNTD collapses duplicates into one. C2 appears once as "Returned." The result is 22 — exactly what's needed. A fails because COUNT counts all non-null values including duplicates. C1 has two Returned records, so COUNT returns 33 (two for C1, one for C2), not 22. C uses SUM(IF ... THEN 1 ELSE 0 END), which counts rows with a Returned status, not distinct customers. Again, C1 contributes 22 to the sum, giving 33 total — same trap as A. D is syntactically invalid in Tableau. You cannot nest an aggregate function like COUNTD inside a row-level IF statement. Tableau will throw an error because the logic levels are mixed. A useful rule of thumb: whenever you need "how many unique things meet a condition," reach for COUNTD wrapping a conditional expression. The IF goes inside COUNTD, not the other way around.

Question 6

An analyst creates this field for use as a text label:

IF [Ship Date] <= TODAY() THEN [Ship Date] ELSE "Pending" END

Tableau reports that the result branches have incompatible data types.

Which revision both resolves the error and preserves the intended text label?

  1. IF [Ship Date] <= TODAY() THEN DATETRUNC('day', [Ship Date]) ELSE "Pending" END
  2. IF [Ship Date] <= TODAY() THEN [Ship Date] ELSE DATE("Pending") END
  3. IF [Ship Date] <= TODAY() THEN [Ship Date] ELSE NULL END
  4. IF [Ship Date] <= TODAY() THEN STR([Ship Date]) ELSE "Pending" END (correct answer)
Explanation: Whenever you see an IF/THEN/ELSE calculation in Tableau, remember this core rule: every branch must return the same data type. Tableau evaluates all possible outputs at once, and if one branch returns a Date while another returns a String, it throws a type-mismatch error — exactly what's happening here with [Ship Date] (Date) versus "Pending" (String). The fix is to make both branches speak the same language. Option D does this cleanly by wrapping [Ship Date] in STR(), which converts the date to a string. Now both branches return String values — a formatted date string when the shipment has arrived, and the literal text "Pending" otherwise. Since the field is intended as a text label, converting to String is not just valid, it's the right semantic choice. Option A fails because DATETRUNC('day', [Ship Date]) still returns a Date — it just truncates the time component. The THEN branch is still a Date while the ELSE branch is still a String, so the error remains. Option B attempts DATE("Pending"), which is nonsensical — Tableau cannot parse the word "Pending" as a date, making this both a type error and a logical impossibility. Option C sidesteps the crash by replacing "Pending" with NULL, which is type-neutral and resolves the mismatch, but it loses the intended label entirely — a null value gives you nothing to display, defeating the purpose of the field. As a study tip: when debugging Tableau type errors in IF/ELSE expressions, always audit every branch for its return type, then pick the conversion function (STR(), DATE(), INT()) that matches the field's intended use.

Question 7

A data source contains three records whose Discount values, in order, are null, 00, and 0.150.15. The following calculated field is evaluated for each record:

IF [Discount] = 0 THEN "None" ELSEIF ISNULL([Discount]) THEN "Missing" ELSE "Applied" END

Which sequence of results does Tableau return for the three records?

  1. "Missing", "None", "Applied" (correct answer)
  2. "None", "None", "Applied"
  3. "Applied", "None", "Applied"
  4. Null, "None", "Applied"
Explanation: When Tableau evaluates an IF/ELSEIF chain, it tests each condition in order and stops at the first one that is true. The critical insight here is how Tableau handles null values in comparisons: any equality check against null — including null = 0 — returns null (which is falsy), not true or false. This means null quietly "falls through" equality checks rather than matching them. For the first record, where Discount is null, Tableau evaluates [Discount] = 0 first. Since null = 0 is null (not true), it moves to ISNULL([Discount]), which returns true, so the result is "Missing". For the second record, Discount is 0, so [Discount] = 0 is immediately true, returning "None". For the third record, Discount is 0.15, which fails both the first and second conditions, so it falls to ELSE "Applied". The correct sequence is "Missing", "None", "Applied" — answer A. Answer B is the classic trap: it assumes null = 0 is true, returning "None" for the null record. This reflects a misunderstanding of null arithmetic in Tableau. Answer C assumes null fails both the equality check and ISNULL(), landing in the ELSE branch — but ISNULL(null) is definitely true. Answer D assumes the entire expression returns null for a null input, as if no branch fires at all, which isn't what happens here since ISNULL catches it. Your study tip: whenever you see null values in an IF chain, mentally flag where the ISNULL() check lives — its position in the order matters enormously, and placing it after an equality check is intentional here.

Question 8

A string parameter named [Metric Selector] contains "Sales", "Profit", or "Margin". For the current marks, total Sales are 800800 and total Profit is 120120. The analyst needs one aggregate calculated field that returns the selected metric. When "Margin" is selected, the field must return aggregate Profit divided by aggregate Sales.

Which calculation is valid and returns 0.150.15 when [Metric Selector] is set to "Margin"?

  1. CASE [Metric Selector] WHEN "Sales" THEN SUM([Sales]) WHEN "Profit" THEN SUM([Profit]) WHEN "Margin" THEN SUM([Sales]) / SUM([Profit]) END
  2. CASE [Metric Selector] WHEN "Sales" THEN [Sales] WHEN "Profit" THEN [Profit] WHEN "Margin" THEN SUM([Profit]) / SUM([Sales]) END
  3. CASE [Metric Selector] WHEN "Sales" THEN SUM([Sales]) WHEN "Profit" THEN SUM([Profit]) WHEN "Margin" THEN AVG([Profit] / [Sales]) END
  4. CASE [Metric Selector] WHEN "Sales" THEN SUM([Sales]) WHEN "Profit" THEN SUM([Profit]) WHEN "Margin" THEN SUM([Profit]) / SUM([Sales]) END (correct answer)
Explanation: When building a dynamic metric selector in Tableau, you need to think carefully about two things simultaneously: aggregation consistency and correct formula logic. Every branch of a CASE statement that returns a value must use the same aggregation level — you can't mix raw row-level fields with aggregates in the same calculated field. Option D is correct. It writes each branch as a proper aggregate — SUM([Sales]), SUM([Profit]), and SUM([Profit]) / SUM([Sales]) — and the Margin branch divides Profit by Sales in the right order: 120÷800=0.15120 \div 800 = 0.15. Tableau accepts this because every branch produces an aggregate result, keeping the calculation valid. Option A has the Margin formula backwards: it computes SUM([Sales]) / SUM([Profit]), which gives 800÷120≈6.67800 \div 120 \approx 6.67, not 0.150.15. This is a straightforward logic error — Margin is always Profit over Sales, not the reverse. Option B mixes unaggregated row-level fields ([Sales], [Profit]) with aggregates (SUM([Profit]) / SUM([Sales])). Tableau will throw an error because you cannot blend aggregate and non-aggregate expressions in the same calculated field. Option C uses AVG([Profit] / [Sales]), which computes the ratio row by row first and then averages those ratios. This is mathematically different from SUM([Profit]) / SUM([Sales]) and will not reliably return 0.150.15 at the aggregate level. Study tip: Whenever you write a multi-branch CASE that includes aggregates, check that every branch is aggregated — and double-check the numerator/denominator order in any ratio formula before moving on.

Question 9

Each row contains Sales and a category-level Target that is repeated for every row in that category. In a view with Category as the dimension, an analyst wants to compare total Sales with the category's Target. The result must be "Met" or "Below" and must not cause Tableau's aggregate/nonaggregate error.

Which calculated field correctly performs the comparison?

  1. IF SUM([Sales]) >= MIN([Target]) THEN "Met" ELSE "Below" END (correct answer)
  2. IF SUM([Sales]) >= [Target] THEN "Met" ELSE "Below" END
  3. IF SUM([Sales]) >= SUM([Target]) THEN "Met" ELSE "Below" END
  4. IF [Sales] >= MIN([Target]) THEN "Met" ELSE "Below" END
Explanation: When working with calculated fields in Tableau, the key rule to internalize is this: you cannot mix aggregate and non-aggregate references in the same expression. The moment your formula includes something like SUM([Sales]), every other field in that formula must also be wrapped in an aggregate function. Option A — IF SUM([Sales]) >= MIN([Target]) THEN "Met" ELSE "Below" END — satisfies this rule perfectly. Since the Target value repeats identically for every row within a category, MIN([Target]) and MAX([Target]) will both resolve to that same single value. Using MIN() is a clean, intentional way to extract that constant while keeping the expression fully aggregated. This is the correct answer. Option B fails immediately because [Target] is referenced without any aggregation alongside SUM([Sales]). Tableau will throw a mixed aggregate/non-aggregate error and refuse to compute the field. Option C is syntactically valid — SUM([Sales]) >= SUM([Target]) avoids the mixing error — but it produces a logically wrong result. Because Target repeats on every row, SUM([Target]) adds up all those repeated values across the category, inflating the target far beyond its intended single value. You'd almost never "Meet" a target that's been multiplied by your row count. Option D has the opposite problem from B: [Sales] is non-aggregate, while MIN([Target]) is aggregate. Same mixing error, just reversed. Study tip: Whenever you see SUM() on one side of a comparison in Tableau, scan every other field in the formula and ask, "Is this also wrapped in an aggregate?" If not, Tableau will reject it.

Question 10

An analyst must classify Profit Ratio using these business rules:

  • Values below 00 are "Loss".
  • Values from 00 up to, but not including, 0.100.10 are "Low".
  • Values of 0.100.10 or greater are "Healthy".

Which Tableau calculation implements the rules correctly, including the boundary values?

  1. IF [Profit Ratio] < 0.10 THEN "Low" ELSEIF [Profit Ratio] < 0 THEN "Loss" ELSE "Healthy" END
  2. IF [Profit Ratio] < 0 THEN "Loss" ELSEIF [Profit Ratio] < 0.10 THEN "Low" ELSE "Healthy" END (correct answer)
  3. IF [Profit Ratio] <= 0 THEN "Loss" ELSEIF [Profit Ratio] <= 0.10 THEN "Low" ELSE "Healthy" END
  4. CASE [Profit Ratio] WHEN < 0 THEN "Loss" WHEN < 0.10 THEN "Low" ELSE "Healthy" END
Explanation: When building conditional classifications in Tableau, the order of your IF/ELSEIF branches is critical — Tableau evaluates them top to bottom and stops at the first true condition. This means you must always place your most restrictive (narrowest) condition first. B is correct because it checks [Profit Ratio] < 0 first, correctly catching all negative values as "Loss". Then ELSEIF [Profit Ratio] < 0.10 catches values from 00 up to (but not including) 0.100.10 as "Low". Everything remaining — values ≥0.10\geq 0.10 — falls into ELSE "Healthy". The boundary value 00 itself is not less than 00, so it correctly falls through to the second condition and receives "Low". Clean, logical, and order-aware. A fails because the conditions are reversed. Checking < 0.10 first means a value like −0.05-0.05 is caught immediately as "Low" — it never reaches the "Loss" branch. Negative values are misclassified entirely. C uses <= instead of <. At the boundary value 00, <= 0 is true, so 00 would be labeled "Loss" — but the rules say 00 should be "Low". The wrong operator mishandles the boundary. D is a syntax trap. Tableau's CASE statement matches exact values (e.g., CASE [Status] WHEN "Active"), not range comparisons. Using WHEN < 0 is invalid syntax and will throw an error. Study tip: In any range-based IF calculation, order branches from narrowest to broadest, and double-check boundary values by mentally plugging in the exact cutoff number (like 00 or 0.100.10) to confirm each lands in the right category.