Preserve Tableau filter order in SQL.

What is the direct answer to this workbook question?

Tableau evaluates six filter layers at different points in its pipeline, and each layer maps to a specific SQL stage. Context filters become WHERE clauses inside FIXED LOD subqueries, standard dimension filters become outer WHERE clauses before GROUP BY, measure filters map to HAVING, and table calculation filters map to QUALIFY.

Why can moving every filter into WHERE change a result?

When an analyst or AI coding agent translates a Tableau worksheet to SQL, the #1 bug is putting every pill from the Tableau Filters shelf into a single WHERE clause.

In Tableau's order of operations, where a filter sits in the pipeline determines whether it filters rows before or after Level of Detail expressions, standard aggregations, and window calculations.

Where do the filter stages belong in SQL?

Context filters affect the input to FIXED calculations; later filters affect later query stages. The table distinguishes those placements.

How can I keep the filter stages in one SQL template?

Suppose a worksheet has:

• A Context Filter on status = 'Completed' (Step 2)
• A FIXED LOD computing total regional sales { FIXED [Region] : SUM([Sales]) } (Step 3)
• A Regular Dimension Filter keeping only category = 'Technology' (Step 4)
• A Measure Filter requiring SUM([Sales]) > 5000 (Step 6)
• A Table Calculation computing RUNNING_SUM(SUM([Sales])) (Step 7)
• A Table Calculation Filter keeping only ranks <= 10 (Step 8)

Here is the exact DuckDB / Snowflake / BigQuery SQL that preserves every stage:

WITH context_filtered AS (
  -- Step 1 & 2: Data Source + Context Filters (Grey Pills)
  SELECT *
  FROM orders
  WHERE status = 'Completed'
),

fixed_lod AS (
  -- Step 3: FIXED LOD computed BEFORE regular dimension filters
  SELECT
    region,
    SUM(sales) AS fixed_region_sales
  FROM context_filtered
  GROUP BY region
),

view_grouped AS (
  -- Step 4, 5 & 6: Dimension Filters (WHERE), View Aggregation (GROUP BY), Measure Filters (HAVING)
  SELECT
    c.region,
    c.state,
    SUM(c.sales) AS tech_state_sales,
    MAX(f.fixed_region_sales) AS total_region_sales_all_categories
  FROM context_filtered c
  JOIN fixed_lod f
    ON c.region = f.region
  WHERE c.category = 'Technology'       -- Step 4: Regular Dimension Filter (Blue Pill)
  GROUP BY c.region, c.state
  HAVING SUM(c.sales) > 5000            -- Step 6: Measure Filter (Green Pill)
),

windowed AS (
  -- Step 7: Table Calculations (Window Functions)
  SELECT
    region,
    state,
    tech_state_sales,
    total_region_sales_all_categories,
    tech_state_sales / total_region_sales_all_categories AS share_of_all_cat_region_sales,
    SUM(tech_state_sales) OVER (
      PARTITION BY region
      ORDER BY tech_state_sales DESC
      ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) AS running_sum_sales,
    RANK() OVER (
      PARTITION BY region
      ORDER BY tech_state_sales DESC
    ) AS sales_rank
  FROM view_grouped
)

-- Step 8: Table Calculation Filter ("Hide without filtering underlying data")
SELECT *
FROM windowed
WHERE sales_rank <= 10;

How can I select a top ten inside a filtered region?

In Tableau, if a user sets a Top 10 Customers by Sales filter and also filters Region = 'East' as a regular blue Dimension Filter, they often see fewer than 10 customers. Why? Because in Tableau's order of operations, Top N filters are not evaluated after regular Dimension Filters—they execute at the Set/Top N stage (or simultaneously with general dimension filters unless ordered via Context), so Region = 'East' does not narrow the pool before the Top 10 are picked unless Region is promoted to a Context Filter.

In Tableau, you fix this by clicking "Add to Context" on Region. In SQL, you fix it by placing WHERE region = 'East' inside the CTE before computing RANK() OVER (ORDER BY SUM(sales) DESC).

What data does this worked example use?

The initial view uses authored synthetic data, not customer data or a captured agent session.

The example record lists its file, calculation or SQL and expected values. The live browser result is computed by xmetric’s existing engine or workbook inspector. Samples are excluded from own-data activation reporting.