Tableau Quiz: Basic Calculated Fields
10 questions · exam conditions
0:00
Basic Calculated FieldsQuestion 1 of 10

The non-null [Customer Name] field must be combined with [Region] in the format Customer Name - Region. When [Region] is null, the result must retain the customer name and use Unassigned as the region.

Which calculated field produces the required label?

[Customer Name] + " - " + IFNULL([Region], "")
IFNULL([Customer Name] + " - " + [Region], "Unassigned")
[Customer Name] + " - " + IFNULL([Region], "Unassigned")
IF ISNULL([Region]) THEN [Customer Name] ELSE [Customer Name] + " - " + [Region] END
← Back to quizzes

Tableau Quiz

Tableau Quiz: Basic Calculated Fields

Practice Basic Calculated Fields 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 Basic Calculated Fields, 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

The non-null [Customer Name] field must be combined with [Region] in the format Customer Name - Region. When [Region] is null, the result must retain the customer name and use Unassigned as the region.

Which calculated field produces the required label?

  1. [Customer Name] + " - " + IFNULL([Region], "")
  2. IFNULL([Customer Name] + " - " + [Region], "Unassigned")
  3. [Customer Name] + " - " + IFNULL([Region], "Unassigned") (correct answer)
  4. IF ISNULL([Region]) THEN [Customer Name] ELSE [Customer Name] + " - " + [Region] END
Explanation: When combining string fields in Tableau, your first instinct should be to identify where the null value lives and what behavior you want when it appears. Here, [Region] can be null, and you want a fallback of "Unassigned" — but the customer name should always appear in the output. IFNULL([Region], "Unassigned") solves this precisely: it returns [Region] when it has a value, and "Unassigned" when it doesn't. Wrapping that inside the full concatenation — [Customer Name] + " - " + IFNULL([Region], "Unassigned") — means you always get a complete, correctly formatted label. That's why C is correct. A fails because IFNULL([Region], "") replaces a null region with an empty string, producing "Customer Name - " instead of "Customer Name - Unassigned". It handles the null but drops the required fallback label. B wraps the entire concatenation in IFNULL. The problem is that in Tableau, any string concatenation involving a null field returns null — so when [Region] is null, the whole expression is null, and IFNULL returns "Unassigned" as the entire result, discarding the customer name entirely. That's the opposite of what you need. D looks logical, but it actually inverts the condition. When [Region] IS null, it returns only [Customer Name] with no suffix — again, losing the "Unassigned" requirement. A useful rule of thumb: apply IFNULL or ZN at the field level, not around the whole expression, so you control exactly what gets substituted without collapsing the rest of your formula.

Question 2

A service request is considered active on both its [Start Date] and its [End Date]. The calculation must return the inclusive number of calendar dates, including when the dates cross a month boundary. For example, January 30 through February 2 covers 44 calendar dates.

Which calculated field returns the required inclusive duration?

  1. DATEDIFF('day', [Start Date], [End Date]) + 1 (correct answer)
  2. DATEDIFF('day', [Start Date], [End Date])
  3. DATEPART('day', [End Date]) - DATEPART('day', [Start Date]) + 1
  4. ABS(DATEPART('day', [End Date]) - DATEPART('day', [Start Date])) + 1
Explanation: When counting inclusive durations in Tableau, the key insight is that DATEDIFF('day', start, end) measures the gap between two dates — not the count of dates themselves. Think of it like fence posts: five posts create four gaps, so to count the posts, you always add one. Option A, DATEDIFF('day', [Start Date], [End Date]) + 1, is correct. Using the passage's example, January 30 to February 2 gives DATEDIFF('day', Jan 30, Feb 2) = 3, and adding 1 returns 44 — exactly the inclusive count required. This approach also handles month boundaries correctly because DATEDIFF works on the actual calendar distance, not raw day numbers. Option B, DATEDIFF('day', [Start Date], [End Date]), returns the exclusive count — it omits the start date. For the example, it returns 33 instead of 44, making it off by one every time. Option C, DATEPART('day', [End Date]) - DATEPART('day', [Start Date]) + 1, extracts only the day-of-month number from each date and subtracts them. For January 30 to February 2, this computes 2−30+1=−272 - 30 + 1 = -27 — a completely wrong result whenever dates span a month boundary. Option D adds ABS() to Option C's approach, which prevents negative numbers but still produces ∣2−30∣+1=29|2 - 30| + 1 = 29 — still wildly incorrect for cross-month ranges. A reliable study tip: whenever a question asks for an inclusive date count in Tableau, reach for DATEDIFF plus 1, and immediately disqualify any formula using DATEPART('day', ...) for duration, since it ignores the month and year components entirely.

Question 3

The numeric field [Store Code] contains values from 00 through 999999. The string field [SKU] is already formatted correctly. A label must contain a three-character, zero-padded store code, a hyphen, and the SKU. For example, store code 77 and SKU 1842 must produce 007-1842.

Which calculated field produces the required label for every valid store code?

  1. LEFT("000" + STR([Store Code]), 3) + "-" + [SKU]
  2. RIGHT("000" + STR([Store Code]), 3) + "-" + [SKU] (correct answer)
  3. RIGHT("000" + STR([Store Code]), 2) + "-" + [SKU]
  4. STR([Store Code]) + "-" + RIGHT("000" + [SKU], 3)
Explanation: When zero-padding a number in Tableau, the classic technique is to prepend extra zeros to the string version of the number, then trim the result to exactly the width you need. The key insight is which side you trim from: you always want to keep the rightmost characters, because that preserves the original digits while the leading zeros fill in any remaining space. Here's why B works. Take store code 77: STR(7) gives "7", and prepending "000" gives "0007". Taking RIGHT("0007", 3) returns "007" — exactly three characters, zero-padded. For store code 4242: "000" + "42" = "00042", and RIGHT("00042", 3) = "042". For a three-digit code like 999999: "000999" → RIGHT(..., 3) = "999". It works for every valid input. A uses LEFT instead of RIGHT. For store code 77, LEFT("0007", 3) returns "000" — it grabs the leading zeros and drops the actual digit entirely. This fails for any non-three-digit code. C uses RIGHT(..., 2), which only returns two characters instead of three. Store code 77 would produce "07-1842" — one character short of the requirement. D applies the zero-padding logic to [SKU] rather than [Store Code], and simply concatenates the raw, unpadded store code. The label for store 77 would output "7-..." with no padding at all. A handy rule to remember: RIGHT + prepended zeros = left-pad. Whenever you see a zero-padding question in Tableau, reach for RIGHT("000..." + STR([Field]), n).

Question 4

The decimal field [Margin Ratio] must be categorized as follows: High for values of at least 0.200.20, Medium for values from 0.100.10 through values below 0.200.20, and Low for values below 0.100.10.

Which calculation assigns every boundary value to the intended category?

  1. IF [Margin Ratio] >= 20 THEN "High" ELSEIF [Margin Ratio] >= 10 THEN "Medium" ELSE "Low" END
  2. IF [Margin Ratio] >= 0.10 THEN "Medium" ELSEIF [Margin Ratio] >= 0.20 THEN "High" ELSE "Low" END
  3. IF [Margin Ratio] > 0.20 THEN "High" ELSEIF [Margin Ratio] > 0.10 THEN "Medium" ELSE "Low" END
  4. IF [Margin Ratio] >= 0.20 THEN "High" ELSEIF [Margin Ratio] >= 0.10 THEN "Medium" ELSE "Low" END (correct answer)
Explanation: When writing tiered IF logic in Tableau, two things must be correct simultaneously: the threshold values must match the specification exactly, and the order of conditions must flow from most restrictive to least restrictive. If you test a broader condition first, the narrower one below it can never be reached. Option D gets both right. It checks [Margin Ratio] >= 0.20 first — correctly assigning High to values at or above 0.200.20 — then checks >= 0.10 for Medium, catching values from 0.100.10 up to (but not including) 0.200.20. Everything below 0.100.10 falls to the ELSE "Low" branch. Every boundary value (0.100.10 and 0.200.20) lands in exactly the intended category. Option A uses >= 20 and >= 10 instead of >= 0.20 and >= 0.10 — the thresholds are off by a factor of 100. Since [Margin Ratio] is a decimal field, virtually every real value would fall to Low. Option B reverses the condition order, checking >= 0.10 before >= 0.20. Because 0.200.20 satisfies >= 0.10, a ratio of 0.200.20 would be labeled Medium instead of High — the High branch is unreachable. Option C uses strict greater-than operators (> 0.20, > 0.10). This means a value of exactly 0.200.20 misses the High branch and becomes Medium, and exactly 0.100.10 misses Medium and becomes Low — both boundary values are misclassified. Study tip: In Tableau IF-ELSEIF chains, always write conditions from highest threshold to lowest, and use >= (not >) when the boundary value belongs in the higher category.

Question 5

The [Email] field always contains exactly one @ character and has no leading or trailing spaces. A calculated field must return only the username portion before @.

Which calculation returns the required username without including the delimiter?

  1. LEFT([Email], FIND([Email], "@") - 1) (correct answer)
  2. LEFT([Email], FIND([Email], "@"))
  3. RIGHT([Email], LEN([Email]) - FIND([Email], "@"))
  4. MID([Email], FIND([Email], "@") + 1, LEN([Email]))
Explanation: When extracting part of a string relative to a delimiter, your core challenge is controlling exactly which characters you include — getting the position right means understanding what FIND() actually returns. For an email like "user@domain.com", FIND([Email], "@") returns 5 — the position of @ itself. Since you want only the characters before that symbol, you need 5 - 1 = 4 characters from the left. That's precisely what A does: LEFT([Email], FIND([Email], "@") - 1) extracts "user" cleanly, without the @. B is the classic off-by-one trap. By omitting the - 1, it passes position 5 directly to LEFT(), which includes the @ character itself — returning "user@" instead of "user". C uses RIGHT() to extract everything after the @, which gives you the domain ("domain.com"), not the username. This would be the correct approach if you wanted the opposite portion. D uses MID() starting at FIND([Email], "@") + 1, which also extracts everything after the @. Like C, it returns the domain side — just using a different function to do it. A useful rule of thumb: when using FIND() to feed into LEFT(), always ask yourself whether the delimiter should be included. If not, subtract 1. The - 1 adjustment is one of the most commonly tested details in Tableau string calculations, so treat it as a deliberate decision every time you write one.

Question 6

A transaction should be flagged for review when its priority is High, regardless of sales amount. A Medium-priority transaction should be flagged only when [Sales] exceeds 10001000. All other transactions should not be flagged.

Which Boolean calculated field represents the review rule correctly?

  1. [Priority] = "High" OR [Priority] = "Medium" OR [Sales] > 1000
  2. ([Priority] = "High" OR [Priority] = "Medium") AND [Sales] > 1000
  3. ([Priority] = "High" AND [Sales] > 1000) OR [Priority] = "Medium"
  4. [Priority] = "High" OR ([Priority] = "Medium" AND [Sales] > 1000) (correct answer)
Explanation: When translating business rules into Boolean logic in Tableau, your job is to map each condition to the right logical operator. The key is recognizing which conditions are independent and which are linked. Read the rules carefully: High priority is flagged no matter what (no Sales condition attached), while Medium priority carries a Sales requirement. That makes D the correct choice: [Priority] = "High" OR ([Priority] = "Medium" AND [Sales] > 1000). The parentheses ensure that the AND between Medium and Sales is evaluated first, then combined with High via OR. A High-priority transaction with $500\$500 in sales? Flagged. A Medium-priority transaction with $1500\$1500? Flagged. A Medium-priority transaction with $800\$800? Not flagged. This matches the rule exactly. A fails because it separates all three conditions with OR, meaning any transaction with [Sales] > 1000 gets flagged, regardless of priority — a Low-priority, $1200\$1200 transaction would incorrectly pass. B uses AND at the top level, requiring [Sales] > 1000 for every flagged transaction, including High priority. A High-priority transaction with $500\$500 in sales would be missed entirely — violating the "regardless of sales amount" rule. C reverses the logic, tying the Sales condition to High priority rather than Medium. A High-priority transaction with $500\$500 would slip through, while Medium-priority transactions would be flagged unconditionally — the opposite of the intent. The study tip: when a rule says "X always, but Y only when Z," that's your signal to write X OR (Y AND Z). Let the parentheses do the heavy lifting.

Question 7

A retailer stores the original transaction amount in [Sales], the discount as a decimal in [Discount], and the unchanged product cost in [Cost]. For example, a sale with [Sales] of 500500, [Discount] of 0.200.20, and [Cost] of 300300 should have a net contribution of 100100.

Which calculated field correctly returns net contribution after reducing sales by the discount and then subtracting the unchanged cost?

  1. [Sales] * (1 - [Discount]) - [Cost] (correct answer)
  2. ([Sales] - [Cost]) * (1 - [Discount])
  3. [Sales] - ([Discount] * [Cost]) - [Cost]
  4. [Sales] - [Discount] - [Cost]
Explanation: When a question asks you to apply a discount to sales and then subtract cost, pay close attention to the order of operations — discounting reduces the sales figure first, and cost is subtracted from whatever remains. The correct approach is to calculate discounted revenue, then subtract cost. With the example values, discounted revenue is 500×(1−0.20)=400500 \times (1 - 0.20) = 400, and subtracting cost gives 400−300=100400 - 300 = 100. That matches the expected net contribution, confirming A — [Sales] * (1 - [Discount]) - [Cost] — is correct. B is a common trap. ([Sales] - [Cost]) * (1 - [Discount]) subtracts cost before applying the discount, which applies the discount to the margin rather than to revenue. Using the example: (500−300)×0.80=160(500 - 300) \times 0.80 = 160, not 100100. Cost is described as unchanged, meaning it shouldn't be discounted. C misapplies the discount entirely — [Discount] * [Cost] discounts the cost rather than the sales. This produces 500−(0.20×300)−300=140500 - (0.20 \times 300) - 300 = 140, which is mathematically inconsistent with the business logic described. D subtracts the discount as a raw decimal from sales: 500−0.20−300=199.80500 - 0.20 - 300 = 199.80. This treats [Discount] as a flat currency amount rather than a percentage multiplier, ignoring the actual sales figure entirely. As a study habit, when you see a word like "reducing" or "after applying," translate it into a multiplicative factor (1−discount)(1 - \text{discount}) and ask yourself which field it should scale — then subtract fixed costs afterward.

Question 8

A calculated field must return [Refund Amount] divided by [Returned Units]. If [Returned Units] is either null or 00, the result must be null rather than zero or an attempted division.

Which calculation satisfies both the null-handling and zero-denominator requirements?

  1. IF ISNULL([Returned Units]) THEN NULL ELSE [Refund Amount] / [Returned Units] END
  2. IF IFNULL([Returned Units], 0) = 0 THEN NULL ELSE [Refund Amount] / [Returned Units] END (correct answer)
  3. ZN([Refund Amount] / [Returned Units])
  4. [Refund Amount] / IFNULL([Returned Units], 1)
Explanation: When a calculation must guard against two failure conditions — null values and zero — you need to collapse both into a single check before dividing. That's the core skill being tested here. The cleanest approach is B: IFNULL([Returned Units], 0) converts any null into 0, so the condition = 0 catches both nulls and genuine zeros in one step. If either condition is true, the formula returns null; otherwise it safely divides. This satisfies the requirement completely with minimal logic. Here's why the other options fall short. A only checks for null with ISNULL(), so if [Returned Units] is actually 0 (not null), the ELSE branch executes and Tableau attempts [Refund Amount]0\frac{\text{[Refund Amount]}}{0}, producing an error or infinity — not null. It handles nulls but misses the zero case. C uses ZN(), which converts null results to zero — the exact opposite of what you want. It doesn't prevent the division, and it replaces null with zero rather than preserving it. D substitutes 1 for null via IFNULL([Returned Units], 1), so a null denominator produces [Refund Amount]1\frac{\text{[Refund Amount]}}{1} — a completely wrong value — and a true zero still causes a division error. A useful rule of thumb: when you need to block both null and zero denominators, convert null to 0 first with IFNULL(..., 0), then check = 0. This collapses two conditions into one and keeps your logic clean. Watch for distractors that handle only one of the two failure cases — that's a common trap on Tableau calculated field questions.

Question 9

An order is Open when [Ship Date] is null. A shipped order is Late only when it was shipped more than 4848 hours after [Order Date]; an order shipped at exactly 4848 hours is On Time.

Which calculated field implements all three rules correctly?

  1. IF ISNULL([Ship Date]) THEN "Open" ELSEIF [Ship Date] > DATEADD('hour', 48, [Order Date]) THEN "Late" ELSE "On Time" END (correct answer)
  2. IF ISNULL([Ship Date]) THEN "Open" ELSEIF [Ship Date] >= DATEADD('hour', 48, [Order Date]) THEN "Late" ELSE "On Time" END
  3. IF ISNULL([Ship Date]) THEN "Open" ELSEIF [Ship Date] > DATEADD('day', 48, [Order Date]) THEN "Late" ELSE "On Time" END
  4. IF ISNULL([Ship Date]) THEN "Late" ELSEIF [Ship Date] > DATEADD('hour', 48, [Order Date]) THEN "Open" ELSE "On Time" END
Explanation: When you see a question like this on the Tableau exam, break it into two independent checks: the null handling and the boundary condition. Getting either one wrong produces an incorrect classification. The passage defines three rules precisely: null Ship Date → "Open"; shipped more than 48 hours after Order Date → "Late"; shipped at exactly 48 hours → "On Time." That word more than is your key signal — it means strictly greater than, not greater than or equal to. Answer A implements this correctly. ISNULL([Ship Date]) catches open orders first, then [Ship Date] > DATEADD('hour', 48, [Order Date]) uses strict inequality, so an order shipped at exactly t+48ht + 48h falls through to "On Time" as required. Answer B fails the boundary test. Using >= marks an order shipped at exactly 48 hours as "Late," directly contradicting the rule that exactly 48 hours is "On Time." Answer C uses DATEADD('day', 48, [Order Date]) instead of 'hour'. This shifts the threshold to 48 days, not 48 hours — a unit error that would classify nearly every shipped order as "On Time" rather than "Late." Answer D swaps the output labels entirely: it returns "Late" when the ship date is null and "Open" when the order is actually late. The logic is structurally backwards and violates both the open-order and late-order definitions simultaneously. A good study habit: whenever a boundary condition appears in the passage (words like more than, at least, fewer than), immediately map it to >, >=, or < before looking at the answer choices. That single step eliminates most distractors.

Question 10

A workbook needs a date-valued field representing the first calendar date of the quarter containing each [Order Date]. The field will later be used on a continuous date axis.

Which calculation returns the required date while preserving a date data type?

  1. DATEADD('quarter', 1, [Order Date])
  2. DATEPART('quarter', [Order Date])
  3. DATETRUNC('quarter', [Order Date]) (correct answer)
  4. DATEDIFF('quarter', #1900-01-01#, [Order Date])
Explanation: When working with date calculations in Tableau, the key distinction to internalize is the difference between truncating a date, extracting a part of a date, and shifting a date. This question tests exactly that. What you need here is the first day of the quarter as an actual date value — something that can sit on a continuous date axis. DATETRUNC('quarter', [Order Date]) does precisely this: it snaps any date back to the first moment of its containing quarter, returning a full date like 2024-01-01 for any order in Q1 2024. This makes C the correct answer — it preserves the date data type and produces the quarter's start date. The distractors each represent a different kind of confusion. A, DATEADD('quarter', 1, [Order Date]), adds one full quarter to the order date, which moves you forward in time rather than anchoring to the quarter's start — useful for forecasting, not for this purpose. B, DATEPART('quarter', [Order Date]), returns an integer (1, 2, 3, or 4) representing which quarter the date falls in. An integer cannot be placed on a continuous date axis as a true date, so this breaks the requirement immediately. D, DATEDIFF('quarter', #1900-01-01#, [Order Date]), also returns an integer — the count of quarters elapsed since a reference date — which again destroys the date data type. A useful rule of thumb: whenever a question asks for a date-typed result, reach for DATETRUNC. If it asks for a number, DATEPART and DATEDIFF are your tools. That distinction alone will resolve a wide range of Tableau date function questions.