Tableau Parameters to Power BI: What-If, Field, and Query Parameters

Tableau defines a parameter as "a workbook variable such as a number, date, or string that can replace a constant value in a calculation, filter, or reference line", and it is global across the workbook. Power BI has no single feature with that reach. One Tableau concept splits into four unrelated mechanisms, and the conversion goes wrong when the wrong one is chosen, not when the DAX is written badly. Start from what the parameter was used for.

Which Power BI parameter to use

What-if parameters: the numeric case

Creating a what-if parameter generates three things at once: a table of values, a measure that returns the current selection, and optionally a slicer. Your own calculations reference the measure, never the column, which is the single most common mistake when converting from Tableau, where the parameter is simply a value you type into a formula.

Two documented limits shape the design. A parameter can hold at most 1,000 unique values, and beyond that the values are evenly sampled, so a Tableau parameter offering every date in a decade needs rethinking rather than porting. And parameters are designed for measures within visuals: Microsoft warns that using one in a dimension calculation might calculate incorrectly. A Tableau parameter used inside a row-level calculated field is therefore not a like-for-like move, and usually becomes a measure instead.

Field parameters: the swap case

The Tableau pattern of a parameter plus a CASE calculation, used to let a viewer choose which measure a chart displays, has a purpose-built equivalent. Field parameters let report readers change the measures or dimensions in a visual from a slicer, and one parameter can mix measures and dimensions. The definition is plain DAX using NAMEOF, so it can be edited directly rather than rebuilt through a dialog.

Check the limitations before promising a like-for-like rebuild. Implicit measures are not supported, so an aggregated column used in the Tableau version needs an explicit measure. Field parameters cannot be created on a live connection without a local model. They cannot be used as the linked field of a drillthrough or tooltip page, though the underlying fields can. And there is no "none" option: selecting nothing is the same as selecting everything.

Parameters that change the query, not the calculation

When the Tableau parameter sat inside custom SQL, the equivalent is a Power Query parameter, and both have the same restriction: they replace literal values, not table names or expressions. To put that control in a report reader's hands rather than a developer's, bind a field to a dynamic M query parameter, which passes a slicer selection into the source query for DirectQuery sources.

Two cautions. Microsoft documents an injection risk when parameter values are concatenated into query text, and recommends consuming them through folding operations or the source's own parameter mechanism instead. And the supported filter types are narrow: relative date, hierarchy slicers, exclude filters and Top N filters are all unsupported, so a Tableau parameter driving anything of that shape needs a different design. Details are in custom SQL to Power BI.

The gap: parameter actions

Tableau's Change Parameter action lets users set a parameter by clicking marks in a viz. Power BI has no feature that writes a value back into a parameter from a selection. The workable substitutes are a field parameter driven by a slicer, a bookmark that switches between prepared states, or a disconnected table whose selection a measure reads back. Each is a design decision rather than a translation, so price parameter actions separately, as with the other Tableau actions.

What Antares does with parameters

Parameters are inventoried rather than assumed. That matters because the same Tableau object splits four ways here, and the split is driven by usage, not by the parameter's own definition: the same parameter can feed a calculation on one sheet and a Top N filter on another.

Where the target is unambiguous, conversion handles it. Where it is not, it is flagged rather than guessed, because a parameter silently rewired to the wrong mechanism produces a report that works and answers a slightly different question. Run the free Analyzer to see how parameters are used across your own workbooks.

Related reading: calculated fields to DAX and sets to DAX. Primary sources: Tableau's parameter documentation and Microsoft's guides to what-if parameters and field parameters.