skip to content

Why does a Tableau FIXED LOD ignore a dimension filter but honour a context filter?

level: seniorimportance: should knowfreq 60%

answer

  1. some filters run earlier than others
  2. one stage of the pipeline sits between them
  3. promoting a filter moves it upstream
  4. the other two keywords do not have this problem

basics

~20 s

Tableau applies context filters before it evaluates FIXED level of detail expressions and ordinary dimension filters after, so only the earlier ones can change what a FIXED expression sees. INCLUDE and EXCLUDE are evaluated after dimension filters and do respond to them.

solid answer

~50 s

Tableau applies filters in a fixed sequence: extract filters, then data source filters, then context filters, then FIXED level of detail expressions, then dimension filters, then INCLUDE and EXCLUDE expressions, then measure filters, and finally table calculations and totals. A `{FIXED [Region] : SUM([Sales])}` is therefore already computed by the time a dimension filter on Category runs, which is why the rest of the sheet drops to the filtered subset while the FIXED number does not move. Promoting that filter to context moves it upstream of the FIXED stage, so the expression is computed against the filtered subset instead. The alternatives are to fold the condition into the expression itself — for example `{FIXED [Region] : SUM(IF [Category] = 'Tech' THEN [Sales] END)}` — or to drive it with a parameter, since a parameter's value is substituted into the calculation rather than applied as a filter. INCLUDE and EXCLUDE sit downstream of dimension filters and need none of this.

code

text · 8 lines
text
// Ignores a dimension filter on Category: computed before it runs
{ FIXED [Region] : SUM([Sales]) }

// Same grain, condition folded in so the intent is explicit
{ FIXED [Region] : SUM(IF [Category] = 'Tech' THEN [Sales] END) }

// Respects dimension filters, because it is evaluated after them
{ EXCLUDE [Sub-Category] : SUM([Sales]) }

go deeper

for a junior

Recall that a FIXED expression can show a number that does not react to a filter, and that this is by design rather than a stale extract. Knowing the symptom is enough at this level.

for a middle

State where FIXED, dimension filters and INCLUDE or EXCLUDE sit relative to each other in Tableau's order of operations, and predict which numbers move when a filter is applied.

for a senior

Diagnose the mismatch on a live dashboard and choose a repair with its cost in mind: fold the condition into the expression, drive it with a parameter, or promote the filter to context knowing that the whole worksheet now runs against a recomputed subset.

for a principal

Set the convention. Decide when a metric is defined as filter-independent, document it, and keep context filters out of the default toolkit so that dashboards stay predictable and cheap as teams copy them.

## The order that explains everything Tableau evaluates a worksheet in a documented sequence. The part that matters for level of detail expressions is: 1. Extract filters 2. Data source filters 3. **Context filters** 4. **FIXED level of detail expressions** 5. Dimension filters 6. **INCLUDE and EXCLUDE level of detail expressions** 7. Measure filters 8. Table calculations, then table calculation filters 9. Reference lines and totals Everything above a stage is visible to it; everything below is not yet applied. FIXED sits at stage 4, so stages 1 to 3 shape its input and stages 5 onward cannot. ## Why the two filters behave differently A **dimension filter** is an ordinary filter pill on a discrete field. It runs at stage 5, after FIXED expressions have already produced their values, so it cannot retroactively change them. The visible symptom is a dashboard where the ordinary measures respond to a filter and one KPI stubbornly does not. A **context filter** is a filter you have explicitly promoted to context. Tableau computes a filtered subset of the data first, and everything downstream — including FIXED expressions — is computed against that subset rather than the full source. That is why promoting a filter to context makes an unresponsive FIXED number start moving. This is not a bug and it is often exactly what you want. `{FIXED [Customer ID] : MIN([Order Date])}` is a customer's acquisition date; it should *not* change when someone filters the view to last month. The problem is only that the same mechanism produces a stale-looking KPI when the intent was for it to follow the filter. ## INCLUDE and EXCLUDE are downstream INCLUDE and EXCLUDE are evaluated at stage 6, after dimension filters. They therefore respect ordinary filters with no special handling. If the goal is simply "compute at a different grain but obey the filters on the sheet", INCLUDE or EXCLUDE is usually the more honest choice than FIXED plus a context filter. ## The three repairs, in order of preference **Fold the condition into the expression.** The most explicit fix is to write the filter inside the aggregate: `{FIXED [Region] : SUM(IF [Category] = 'Tech' THEN [Sales] END)}`. The intent is visible in the calculation itself and it survives someone rearranging the filter shelf. The cost is that the condition is now hard-coded in one place. **Drive it with a parameter.** A parameter is not a filter — its current value is substituted into the calculation before the query runs — so a parameter referenced inside a FIXED expression does affect it. This is the standard way to give users a control that a FIXED expression actually obeys. **Promote the filter to context.** Simple and general, but it changes the whole worksheet: every query on the sheet now runs against the context subset, and Tableau must recompute that subset whenever the context filter's selection changes. On a large source that is real work, and it is why "add everything to context" is an anti-pattern rather than a default. ## A symptom checklist - A KPI card that never moves while the rest of the dashboard filters — a FIXED expression above a dimension filter. - A percent-of-total whose parts do not add to 100% after filtering — the denominator is a FIXED whole-table total computed pre-filter. - Totals that changed when someone added a filter to context — expected, and the reason context changes need review, not just a click. ## Not the same thing as filter context elsewhere The vocabulary across BI tools rhymes and the mechanisms do not. Tableau's *context filter* is a pre-computed subset of the data that upstream stages see; Power BI's *filter context* is the set of filters a DAX measure is evaluated under, manipulated by functions such as `CALCULATE` and `ALL`. Neither is the other, and a candidate who explains one using the other's mechanism is telling the interviewer they have only read about one of them. ## What interviewers listen for They want the ordering, stated plainly, and the consequence drawn from it rather than memorised as a rule. Strong answers add that INCLUDE and EXCLUDE behave differently because they sit lower in the order, offer the in-expression condition as a repair before reaching for context, and mention that context filters are not free.

  • Do INCLUDE and EXCLUDE expressions also ignore dimension filters?
    No. They are evaluated after dimension filters, so they see the filtered data and behave like ordinary aggregates in that respect. That makes them the simpler choice whenever the requirement is "different grain, same filters". FIXED is the right tool only when the number genuinely should not move — a customer's acquisition date or a whole-table denominator.
  • What does promoting a filter to context actually cost?
    Tableau computes a filtered subset of the data first and runs the sheet's queries against it, so every change to the context filter's selection forces that subset to be recomputed. On a large source that is a noticeable delay, and it applies to the whole worksheet, not just the calculation you were trying to fix. Use it deliberately, not as a reflex for every unresponsive number.
  • Why does a parameter influence a FIXED expression when a filter does not?
    A parameter is not part of the filter pipeline. Its current value is substituted into the calculation before the query is generated, so a FIXED expression that references a parameter is computed with that value baked in. This makes parameters the usual way to give users an interactive control that a FIXED expression genuinely responds to, at the cost of single-select behaviour rather than a filter's multi-select.
  • A percent-of-total built on a FIXED denominator no longer sums to 100% after filtering. What happened?
    The numerator is an ordinary aggregate that respects the dimension filter, while the FIXED denominator was computed before that filter ran, so it still reflects the unfiltered population. Either promote the filter to context so both see the same data, or replace the denominator with an EXCLUDE expression, which is evaluated after dimension filters and therefore stays consistent with the numerator.

saying these in an interview costs you the question

  • Claims FIXED respects whatever filters sit on the sheet
  • Adds every filter to context until the numbers agree
  • Explains Tableau's context filter as Power BI's filter context
  • Assumes INCLUDE behaves identically to FIXED under filters
  • Treats a stubborn KPI as a caching or refresh problem

context

resolving links…