Tableau Calculated Fields Returning Null: Fix Type Mismatch and Aggregation Errors

You build a calculated field in Tableau, drag it onto the view, and every row shows Null. No error message, no red underline — just silence. It's one of the most frustrating experiences in Tableau because the tool doesn't always tell you what went wrong or where.

The good news: almost every null-returning calculation comes from one of two root causes. Once you know how to spot them, you can fix most issues in under five minutes.

• Why Tableau returns null from calculated fields instead of an error
• How type mismatches silently break string, number, and date calculations
• How aggregation level mismatches cause null across an entire view
• Practical patterns for safe type conversion and mixed-granularity calculations
• A systematic debugging checklist you can use on any calculation

Why Tableau Returns Null Instead of an Error

In most programming languages, dividing by zero or concatenating a number with a string throws an exception. Tableau takes a different approach: it propagates null. When any part of an expression can't be evaluated, the result becomes null rather than crashing the workbook.

This design makes workbooks more resilient, but it shifts the debugging burden onto you. A broken sub-expression anywhere in a long formula will quietly poison the entire output. The implication is important: if a field returns null, the problem might not be in the part of the formula you're looking at.

The Two Root Causes You Need to Know

Before reaching for ZN() or IFNULL() to paper over nulls, identify which of these two problems you actually have. The fixes are completely different.

• Type mismatch — you're passing the wrong data type to a function, or trying to mix incompatible types in an expression.
• Aggregation mismatch — you're mixing aggregated (e.g., SUM([Sales])) and non-aggregated fields in the same expression at the wrong level.

A third, less common cause is a genuine null in the underlying data propagating through your formula — but handle that only after you've ruled out the first two.

Diagnosing Type Mismatch Errors

Tableau's data types are strict at runtime even when the calculation editor doesn't flag an obvious red border. The core types are String, Number (Integer and Float), Date, Date & Time, and Boolean. Feeding a String where a Number is expected — or vice versa — returns null for that row.

Spotting a type problem

Open the Data pane and look at the icon next to the field you're pulling into your calculation. A globe means String, a hash means Number, a calendar means Date. If the icon doesn't match what the function expects, you have a type problem.

The most common scenario: a field that looks like a number is actually stored as a string. This happens after Excel imports, CSV extracts, or when a database column has mixed values that forced Tableau to default to String.

// This returns Null if [Revenue] is a String field, not a Number:
[Revenue] * 1.1

// Fix — cast it explicitly:
FLOAT([Revenue]) * 1.1

String and number concatenation

Tableau's string concatenation operator (+) does not auto-cast numbers. If you write [OrderID] + " - " + [CustomerName] and OrderID is an integer, the whole expression returns null.

// Broken — OrderID is an integer:
[OrderID] + " - " + [CustomerName]

// Fixed — cast to string first:
STR([OrderID]) + " - " + [CustomerName]

Date functions with string inputs

Functions like DATEPART(), DATEDIFF(), and DATEADD() require an actual Date or Date & Time field. If your date column was imported as a String (common with ISO date strings from APIs), every date function you call on it returns null.

// Broken — [OrderDate] is a String "2024-03-15":
DATEPART('month', [OrderDate])

// Fixed — parse the string to a date first:
DATEPART('month', DATE([OrderDate]))

If DATE() still returns null, the string format may not match what Tableau can parse automatically. In that case, extract the components manually using string functions, or fix the type at the data source level before connecting.

Boolean context errors

Tableau Boolean fields hold True or False, not 1 or 0. If you write arithmetic directly on a Boolean — such as [IsReturned] * [Revenue] — you'll get null. Use an IF statement to convert: IF [IsReturned] THEN [Revenue] ELSE 0 END.

Diagnosing Aggregation Mismatch Errors

This one bites experienced Tableau users too. The rule is simple to state but easy to violate: you cannot mix aggregated and non-aggregated fields in the same expression unless you're inside a Level of Detail (LOD) expression.

// Broken — SUM() is aggregated, [Target] is row-level:
SUM([Sales]) / [Target]

// Option 1 — aggregate both:
SUM([Sales]) / SUM([Target])

// Option 2 — use an LOD if you need row-level target:
SUM([Sales]) / {FIXED [Region] : MAX([Target])}

The calculation editor will usually warn you with a red error message when this happens. But there's a subtler version of this problem that produces null without any editor error.

The silent aggregation problem: table calcs referencing row-level fields

Table calculations like RUNNING_SUM() or WINDOW_AVG() operate on the aggregated result set, not on individual rows. Referencing a non-aggregated dimension inside them creates an undefined result that resolves to null in many configurations.

LOD expressions and aggregation scope

LOD expressions (FIXED, INCLUDE, EXCLUDE) evaluate at a different granularity than the view. When you reference an LOD result in a calculation alongside a view-level aggregate, make sure both sides are aggregated consistently in the outer expression.

// LOD giving the customer's first order date:
{FIXED [Customer ID] : MIN([Order Date])}

// Using it in a view-level calc — wrap in an aggregate:
DATEDIFF('day', 
  MIN({FIXED [Customer ID] : MIN([Order Date])}),
  MIN([Order Date])
)

Without the outer MIN() wrapping the LOD expression, Tableau can't reconcile the granularities and the field returns null in the view.

A Systematic Debugging Checklist

When a calculated field returns null, run through these steps in order before changing your formula.

1. Check field types in the Data pane. Hover over each field used in the calculation and confirm the type matches what the function expects.
2. Isolate sub-expressions. Create a new calculated field containing only one piece of your formula and drop it in the view. Narrow down which part is returning null.
3. Check aggregation consistency. If the calculation editor shows a red error about mixing aggregated and non-aggregated, fix that first — it's the most likely cause.
4. Add a row count check. Create a calc that's just 1 (a number literal). If it returns values, your connection is fine and the problem is in the formula logic.
5. Look at the raw data. Use the View Data feature (right-click a mark, select View Data) to see whether the underlying field values are null before the calculation touches them.
6. Test type conversions individually. Before wrapping your whole expression in FLOAT() or DATE(), test those conversions alone to confirm they succeed.

Common Patterns That Quietly Return Null

Division by zero

Tableau returns null for division by zero rather than infinity or an error. If your denominator can be zero in any row, protect against it explicitly.

// Safe division pattern:
IF SUM([Quantity]) != 0
THEN SUM([Revenue]) / SUM([Quantity])
ELSE NULL
END

Returning explicit NULL in the else branch is intentional — it's honest about the fact that the value is undefined, rather than substituting a misleading zero.

CASE and IF with incomplete branches

If a CASE or IF statement doesn't cover every possible value, Tableau returns null for unmatched rows. Always include an ELSE clause, even if it just returns "Other" or 0.

// Risky — what happens if Status is 'Pending'?
CASE [Status]
  WHEN 'Complete' THEN 1
  WHEN 'Cancelled' THEN 0
END

// Safer:
CASE [Status]
  WHEN 'Complete' THEN 1
  WHEN 'Cancelled' THEN 0
  ELSE NULL  // or a default value
END

Parameters with mismatched data types

If you use a parameter in a calculation, its data type must match how it's used. A String parameter compared to a Number field with = will return null for every row without raising an error in the editor.

When the Data Itself Is Null

Once you've ruled out type and aggregation issues, check whether the source data genuinely contains nulls. Use a simple diagnostic calc to count them:

// Count of null values in a field:
IF ISNULL([Revenue]) THEN 1 ELSE 0 END

Sum this in the view to see how many rows have null source values. If the number is higher than expected, the fix lives upstream — in your SQL query, data preparation step, or source system — not in Tableau.

If fixing the data isn't practical, use ZN() to substitute zero for null numbers, or IFNULL([Field], "default") for strings. Use these as a last resort, not a first response, because masking nulls hides real data quality problems.

Wrapping Up

Null-returning calculated fields are almost never random — they follow a pattern, and that pattern points directly to the fix. Here are four concrete actions to take right now:

• Audit field types on any calculation that returns null. Open the Data pane, check the icon next to each field, and add explicit cast functions (FLOAT(), STR(), DATE()) where needed.
• Isolate sub-expressions into temporary calculated fields. Drop each one into the view individually until you find the one that returns null — then fix only that part.
• Add ELSE clauses to every IF and CASE statement in your workbook. An unmatched branch is a silent null factory.
• Use the View Data panel before assuming the problem is your formula. If the source field is already null, fix it upstream.
• Wrap LOD expressions in an aggregate function when using them in view-level calculations to avoid granularity conflicts.

With these habits in place, most null mysteries resolve themselves within a few minutes — no guessing required.