Tableau Quiz: Handling Nulls
10 questions · exam conditions
0:00
Handling NullsQuestion 1 of 10

One mark contains two records. Their Profit values are null and 2020, and both records have Sales of 100100. The analyst calculates AVG(IFNULL([Profit] / [Sales], 0)).

What result does this calculation produce?

0.200.20, because IFNULL is ignored and only the record with non-null profit contributes to the average
0.100.10, because the null row becomes zero and is included in the average
00, because a null in any input causes the entire average to return zero
0.400.40, because the non-null ratio is applied once for each underlying record
← Back to quizzes

Tableau Quiz

Tableau Quiz: Handling Nulls

Practice Handling Nulls 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 Handling Nulls, 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

One mark contains two records. Their Profit values are null and 2020, and both records have Sales of 100100. The analyst calculates AVG(IFNULL([Profit] / [Sales], 0)).

What result does this calculation produce?

  1. 0.200.20, because IFNULL is ignored and only the record with non-null profit contributes to the average
  2. 0.100.10, because the null row becomes zero and is included in the average (correct answer)
  3. 00, because a null in any input causes the entire average to return zero
  4. 0.400.40, because the non-null ratio is applied once for each underlying record
Explanation: When you see a question combining IFNULL with an aggregate like AVG, the key is understanding when IFNULL fires — it operates at the row level, before aggregation happens. Think of it as a two-stage process: first, transform each row's value; then, aggregate the results. Here's how it unfolds: Record 1 has Profit=null\text{Profit} = \text{null}, so null/100=null\text{null} / 100 = \text{null}, and IFNULL(null, 0) returns 00. Record 2 has Profit=20\text{Profit} = 20, so 20/100=0.2020 / 100 = 0.20, and IFNULL(0.20, 0) returns 0.200.20. Now AVG sees two values: 00 and 0.200.20. Their average is (0+0.20)/2=0.10(0 + 0.20) / 2 = \mathbf{0.10}, confirming B. A is wrong because it claims the null row is excluded from the average entirely — that's the default behavior of AVG without IFNULL. Here, IFNULL explicitly converts the null to 00, so it does participate in the denominator count. C confuses IFNULL with how nulls propagate in raw arithmetic. Without the IFNULL, a null input would cause that row's ratio to be null and get excluded — but it wouldn't zero out the entire AVG. D invents a logic where the non-null ratio doubles; no such rule exists. Each record contributes exactly once. The study tip: always trace calculations from the inside out. IFNULL wraps the row-level expression, so it resolves before AVG ever sees the values. Knowing this order prevents the most common trap on aggregation questions.

Question 2

Both Ship Date and Order Date are date fields. An analyst needs a date-valued calculation that uses Order Date only when Ship Date is null.

Which calculation meets the requirement without creating a data-type conflict?

  1. IFNULL([Ship Date], [Order Date]), with both alternatives remaining date values (correct answer)
  2. ZN([Ship Date]), with a numeric zero representing every unshipped order
  3. IFNULL([Ship Date], "Not shipped"), with text replacing each missing date
  4. IFNULL(STR([Ship Date]), [Order Date]), with a string used before a date
Explanation: When working with Tableau calculations that handle null values, you need to think about type consistency — every branch of a conditional expression must return the same data type, or Tableau will throw an error (or silently corrupt your results). IFNULL(expr1, expr2) returns expr1 if it isn't null, and expr2 otherwise. The critical rule is that both expressions must be the same data type. In choice A, IFNULL([Ship Date], [Order Date]) places two date fields side by side — when Ship Date is null, Order Date (also a date) fills in seamlessly. This satisfies the requirement perfectly: the result is always a date, and there's no type mismatch. A is correct. Choice B uses ZN([Ship Date]), which is designed for numeric fields — it replaces nulls with zero. Applying it to a date field is invalid in Tableau, and even conceptually, a numeric zero is not a date value. Choice C passes the type-consistency check in a different, harmful way: IFNULL([Ship Date], "Not shipped") mixes a date with a string, which Tableau will reject as a type conflict. You'd need to convert Ship Date to a string first, but then you'd lose the date entirely — failing the original requirement. Choice D does exactly that mistake deliberately: STR([Ship Date]) converts the date to a string, so now both arguments would need to be strings, but [Order Date] is still a date, creating yet another mismatch. Study tip: On Tableau questions involving IFNULL, IIF, or IF/ELSE, always verify that every possible return value shares the same data type — this is one of the most common sources of calculation errors on the exam.

Question 3

A data source contains two records. For the first record, Unit Price is null and Discount is 0.100.10. For the second record, Unit Price is 100100 and Discount is null. A calculated field is defined as ZN([Unit Price]) * (1 - IFNULL([Discount], 0)).

What is the sum of the calculated field across both records?

  1. 00, because a null in either original field makes the entire sum null
  2. 9090, because the first record's discount is applied to the second record's price
  3. 100100, because the first record contributes zero and the second contributes its full price (correct answer)
  4. 110110, because the null price is replaced with the non-null discount value
Explanation: When working with null-handling functions in Tableau, the key is to evaluate each function independently and trace the calculation record by record before summing. ZN() converts nulls to zero and leaves non-null values unchanged. IFNULL(expr, replacement) returns the expression if it's non-null, otherwise returns the replacement. These functions operate on each record in isolation — they don't borrow values across rows. For Record 1: ZN(null) returns 00, and IFNULL(0.10, 0) returns 0.100.10, giving 0×(1−0.10)=0×0.90=00 \times (1 - 0.10) = 0 \times 0.90 = 0. For Record 2: ZN(100) returns 100100, and IFNULL(null, 0) returns 00, giving 100×(1−0)=100×1=100100 \times (1 - 0) = 100 \times 1 = 100. The sum across both records is 0+100=1000 + 100 = 100, making C correct. A is wrong because ZN() and IFNULL() are specifically designed to handle nulls gracefully — neither record produces a null result, so nulls never propagate into the sum. B reflects a common misconception that Tableau somehow pairs values across records; it doesn't — each record's fields are self-contained. D is nonsensical; there's no mechanism by which a null price would inherit a discount value from another field. As a study tip, always evaluate null-handling functions one record at a time before aggregating. Draw a small table showing each record's intermediate result — this prevents you from falling into traps about null propagation or cross-record contamination.

Question 4

An analyst defines a fallback measure as IFNULL([Actual Sales], IFNULL([Forecast Sales], [Budget Sales])). For one record, Actual Sales is 00, Forecast Sales is 120120, and Budget Sales is 100100.

What value does the fallback measure return, and why?

  1. 220220, because the non-null forecast and budget values are combined
  2. 100100, because the nested calculation evaluates the innermost fallback first
  3. 120120, because zero is treated as missing when a forecast is available
  4. 00, because zero is non-null and the first expression is accepted (correct answer)
Explanation: When working with IFNULL in Tableau, the critical concept to internalize is that it checks for null, not for zero or any other "empty-feeling" value. IFNULL(expr1, expr2) returns expr1 if it is non-null — full stop. The value of expr1 is irrelevant as long as it exists. Here, the outer IFNULL evaluates [Actual Sales] first. Since Actual Sales is 00, and 00 is a legitimate, non-null numeric value, the condition is satisfied immediately. Tableau accepts 00 and returns it — the inner IFNULL([Forecast Sales], [Budget Sales]) is never reached. So D is correct: the fallback measure returns 00. A is wrong because IFNULL never sums or combines values from multiple branches. It selects one expression and stops — there is no aggregation happening here. B is wrong because IFNULL evaluates left to right, outermost first, not innermost first. The nested fallback only triggers if the outer expression is null, which it isn't. C is the most tempting trap: it assumes 00 signals "missing data," which is a natural human intuition but not how Tableau logic works. Zero is a real, stored value — only the absence of any value (null) triggers the fallback. The key study tip: never confuse null with zero in Tableau. Functions like IFNULL, ZN, and ISNULL all hinge on this distinction. On exam questions, if you see 00 as an input, treat it as a valid value unless told otherwise — it will never trigger a null-handling fallback.

Question 5

For a task, Start Date is January 11, End Date is null, and TODAY() is January 1111 of the same year. An analyst compares IFNULL(DATEDIFF('day', [Start Date], [End Date]), 0) with DATEDIFF('day', [Start Date], IFNULL([End Date], TODAY())).

What do the two calculations return, respectively?

  1. 00 and 00, because a null end date prevents either calculation from evaluating
  2. 1010 and 00, because DATEDIFF substitutes the current date before IFNULL is evaluated
  3. 1010 and 1010, because both calculations replace a null end date with the current date
  4. 00 and 1010, because the first replaces a null result while the second replaces the missing endpoint (correct answer)
Explanation: When working with null-handling functions in Tableau, the critical skill is understanding where in the calculation the null substitution occurs — because that changes what gets computed entirely. In the first expression, IFNULL(DATEDIFF('day', [Start Date], [End Date]), 0), Tableau evaluates DATEDIFF first. Since End Date is null, DATEDIFF cannot compute a date difference and returns null. Only then does IFNULL step in, replacing that null result with 00. So the first calculation returns 00. In the second expression, DATEDIFF('day', [Start Date], IFNULL([End Date], TODAY())), the IFNULL is nested inside as an argument. Tableau resolves the inner function first: since End Date is null, IFNULL substitutes TODAY() (January 11). Now DATEDIFF receives two valid dates — January 1 and January 11 — and computes 11−1=1011 - 1 = 10. So the second calculation returns 1010. This confirms D. A is wrong because nulls don't freeze both calculations — only DATEDIFF with a null input returns null; wrapping it correctly still produces a usable result. B reverses the outputs and misattributes how DATEDIFF handles nulls — it doesn't substitute the current date on its own. C is wrong because the first expression never reaches a valid date difference; it replaces a null output, not a null input, so it never computes 1010. The key study takeaway: in Tableau, argument order matters. Wrapping a function's output in IFNULL is very different from substituting a null input before the function runs.

Question 6

A sales data source has records for January and March but has no February records at all. An analyst creates ZN(SUM([Sales])) and expects a February mark with sales of 00.

Which statement best describes the result?

  1. The calculation automatically creates February and displays 00 because ZN completes missing dates
  2. The calculation creates February only when at least one January or March sales value is null
  3. The calculation cannot create the absent February member; domain completion or scaffolding is also required (correct answer)
  4. The calculation converts March to February because ZN shifts values into the first missing period
Explanation: Whenever you see a question about missing date members in Tableau, it's crucial to distinguish between null values and absent dimension members — these are fundamentally different problems requiring different solutions. ZN() is a null-handling function. It converts null values to 00, but it has absolutely no ability to generate dimension members that don't exist in the underlying data. If February has zero records, February simply doesn't exist as a row anywhere in the data source — there's nothing for Tableau to evaluate ZN() against. The calculation never runs for February because there's no February context to run it in. This is why C is correct: you need domain completion (enabling "Show Missing Values" on a date field) or scaffolding (a separate date dimension joined to your data) to first create the February member before any calculation can populate it. A describes a capability ZN() doesn't have — it conflates null-value replacement with dimension member generation. These are separate concerns entirely. B introduces a nonsensical condition; whether January or March values are null is completely irrelevant to whether February appears as a mark. D is a fabricated behavior — ZN() performs no date shifting or value redistribution whatsoever. A useful mental model: think of ZN() as a filter that catches nulls after Tableau has already built the view's axis. If a date was never in the data, the axis never included it, and ZN() never gets a chance to act. For the exam, anytime you see "missing period" or "gap in dates," immediately think scaffolding or domain padding — not null functions.

Question 7

For one record, City is null and State is CA. The calculation [City] + ", " + IFNULL([State], "Unknown") is used to create a location label.

The existing calculation returns null. Which revision returns Unknown, CA while preserving non-null city and state values on other records?

  1. IFNULL([City], "Unknown") + ", " + IFNULL([State], "Unknown") (correct answer)
  2. IFNULL([City] + ", " + [State], "Unknown")
  3. [City] + ", " + IFNULL([State], "Unknown")
  4. IFNULL([City], [State]) + ", " + "Unknown"
Explanation: When working with null values in Tableau string calculations, the most important rule to internalize is this: any arithmetic or concatenation operation involving null produces null. So if [City] is null, the expression [City] + ", " + anything collapses entirely to null — no matter how carefully you wrap the other fields. That's exactly the trap in the original calculation and why choice A is the correct revision. By wrapping each field individually — IFNULL([City], "Unknown") + ", " + IFNULL([State], "Unknown") — you substitute a fallback value before the concatenation happens. When City is null and State is CA, this becomes "Unknown" + ", " + "CA", which returns Unknown, CA. For records where both fields have values, the IFNULL wrappers simply pass the original values through, preserving the normal output. Choice B, IFNULL([City] + ", " + [State], "Unknown"), wraps the entire expression, so when City is null, the whole thing evaluates to null first, and then IFNULL replaces that null with the single string "Unknown" — you lose State entirely. Choice C is the original flawed logic: it only protects State from being null, not City, so a null City still poisons the concatenation. Choice D, IFNULL([City], [State]) + ", " + "Unknown", substitutes State for City when City is null, but then hardcodes "Unknown" as the second part — breaking all records where State is not actually unknown. A useful pattern to remember: in Tableau, protect each field individually with IFNULL before combining them, not the combined result after the fact.

Question 8

Within one mark, Score has three underlying values: 1010, null, and 2020.

How do AVG(IFNULL([Score], 0)) and IFNULL(AVG([Score]), 0) differ for this mark?

  1. They return 1010 and 1515, respectively, because replacement occurs at different levels (correct answer)
  2. They return 1515 and 1010, respectively, because aggregate nulls are replaced first
  3. They both return 1010 because Tableau always converts null measures to zero before averaging
  4. They both return 1515 because averaging always excludes null values before any calculation
Explanation: When working with IFNULL and aggregation in Tableau, the critical question is: at what level does the null replacement occur? The order of operations — whether you handle nulls before or after aggregating — determines the result entirely. With AVG(IFNULL([Score], 0)), Tableau first replaces each null with 00 at the row level, giving you three values: 1010, 00, and 2020. It then averages those: (10+0+20)÷3=10(10 + 0 + 20) \div 3 = 10. With IFNULL(AVG([Score]), 0), Tableau first computes AVG([Score]), which natively excludes nulls, giving (10+20)÷2=15(10 + 20) \div 2 = 15. Since that result isn't null, the outer IFNULL changes nothing, and the final answer is 1515. So the two expressions return 1010 and 1515, respectively — confirming A is correct. B reverses the two values, swapping which formula produces 1010 and which produces 1515 — a simple mix-up of the order-of-operations logic. C is wrong because Tableau does not automatically convert null measures to zero; nulls are excluded from aggregations unless you explicitly replace them. D is partially true — AVG does exclude nulls natively — but it incorrectly concludes both expressions return 1515, ignoring that IFNULL wrapping at the row level forces the null into the calculation as 00. As a study habit, always ask yourself: is the function acting on individual rows or on the aggregate? Wrapping IFNULL inside an aggregate versus outside it produces fundamentally different results, and Tableau questions frequently test exactly this distinction.

Question 9

A text data source preserves empty strings as distinct from nulls. For one customer, Phone is an empty string, Email is customer@example.com, and the calculation is IFNULL([Phone], IFNULL([Email], "No contact")).

What does the calculation return for this customer?

  1. customer@example.com, because an empty phone value is skipped like a null value
  2. No contact, because the first expression lacks visible text and ends the evaluation
  3. An empty string, because it is non-null and is therefore the first accepted value (correct answer)
  4. A null value, because nested IFNULL cannot evaluate an empty-string input
Explanation: When working with IFNULL in Tableau, the single most important thing to keep in mind is that it tests strictly for null — not for blank, empty, or visually absent values. A text data source treats an empty string ("") and a null as two completely different things, and IFNULL only replaces the latter. Here's how the calculation evaluates for this customer: IFNULL([Phone], IFNULL([Email], "No contact")). Tableau first checks whether [Phone] is null. Because [Phone] is an empty string, it is not null — it is a valid, non-null value that simply contains no characters. IFNULL immediately returns it, and the nested expression never even runs. The result is an empty string, making C correct. Choice A is wrong because it assumes Tableau treats empty strings like nulls and "skips" them. It does not — empty strings pass the IFNULL check and are returned as-is. Choice B is wrong for the same underlying reason: the evaluation does not "end" in a failure state; it ends successfully with the empty string as the accepted output. Choice D is wrong because IFNULL is perfectly capable of handling empty-string input — there's no error or null produced; the function simply returns the empty string it received. A useful rule of thumb: whenever you see IFNULL, ask yourself "is the value literally null, or just empty-looking?" If a data source can preserve empty strings, those two things are not interchangeable. Consider using IIF(TRIM([Phone]) = "", ...) if you want to treat blank strings the same as nulls.

Question 10

A group contains three existing records whose Amount values are null, 00, and 55.

What are the results of COUNT([Amount]) and COUNT(ZN([Amount])), respectively?

  1. 11 and 22, because both calculations exclude the original null record
  2. 22 and 33, because ZN makes the formerly null value countable (correct answer)
  3. 22 and 22, because COUNT excludes both null values and numeric zeros
  4. 33 and 33, because COUNT includes every existing record automatically
Explanation: Whenever you see a question combining COUNT with ZN, focus on one core rule: Tableau's COUNT function ignores null values but does count numeric zeros. Your three records have values: null, 00, and 55. Because COUNT([Amount]) skips nulls, it counts only the 00 and the 55, returning 22. Now apply ZN([Amount]): this function replaces null with 00, leaving zeros and non-nulls unchanged. Your dataset effectively becomes 00, 00, and 55 — three non-null values. So COUNT(ZN([Amount])) returns 33. That confirms answer B is correct: the results are 22 and 33. A is wrong because it claims COUNT([Amount]) returns 11, as if it also excluded the zero. That's the trap — COUNT does not filter out zeros, only nulls. C reinforces that same misconception by suggesting COUNT skips zeros, making both results 22. Zeros are perfectly valid, countable values in Tableau. D claims both return 33 by assuming COUNT includes every record regardless. If that were true, nulls would be counted too, which contradicts how COUNT actually works. A useful memory anchor: think of ZN as a null-to-zero converter. It doesn't create new records or remove anything — it just makes formerly uncountable nulls countable by giving them the numeric value 00. On the exam, watch for questions that pair ZN with aggregate functions like COUNT, SUM, or AVG, since each one treats nulls and zeros differently.