Tableau Parameters to Power BI Slicers and Field Parameters

Why parameters feel different

In Tableau, a parameter is a workbook-scoped value. Calculations, filters, reference lines, and sheet swapping can all read it. Authors often use one parameter for several jobs at once (metric picker + date grain + “view mode”).

Power BI does not have a single identical object. Similar behavior is split across:

Slicers (and filters) on model columns or disconnected tables
What-if parameters for numeric scenario inputs
Field parameters for swapping measures or dimensions in visuals
Bookmarks and buttons for discrete layout or page modes
DAX measures (SWITCH, SELECTEDVALUE) that react to those controls

Migration fails when every Tableau parameter is forced into a what-if parameter or a single slicer. Classify the intent first, then pick the Power BI pattern.

Inventory what each parameter actually does

For every Tableau parameter, document:

Data type and allowed values (list, range, all)
Where it is referenced (calcs, filters, titles, actions, dynamic zone visibility)
Primary intent — pick one primary from the table below
Whether values come from a hard-coded list or a field (dynamic parameters)

Intent → Power BI pattern

Tableau intent	Preferred Power BI approach	Avoid
Filter a dimension to one/few values	Slicer on the dimension (or disconnected bridge table)	What-if parameter
Switch which measure appears	Field parameter, or `SWITCH` measure driven by a slicer table	Bookmarks alone for many metrics
Switch which dimension is on an axis	Field parameter	Duplicating visuals per dimension
Numeric threshold / what-if	What-if parameter + measures that read it	Storing the number only in a bookmark
Change chart type or whole layout	Bookmarks + buttons, or separate report pages	One overloaded parameter
Toggle show/hide of containers	Bookmarks / selection pane patterns; or separate pages	Expecting Tableau-style parameter-driven containers 1:1
Dynamic list from a field	Slicer on that field (or synced field parameter options)	Hard-coding a stale list

How to implement the redesign

1. Export the parameter catalog

From each workbook (or a governance extract), list parameters with calc references. Group duplicates across workbooks (“Metric Select” appearing 40 times) so you can standardize one pattern.

2. Rebuild by pattern family

Filter parameters
Create or reuse the dimension in the semantic model. Use a slicer. If the Tableau parameter filtered across sources oddly, fix the model relationships instead of inventing a disconnected filter first.

Metric / dimension switchers
Create a field parameter (Power BI Desktop: Modeling → New parameter → Fields) or a small disconnected table (Metric = {"Revenue","Margin",...}) with a measure:

Selected Metric =
VAR s = SELECTEDVALUE ( Metric[Metric] )
RETURN
SWITCH (
    s,
    "Revenue", [Revenue],
    "Margin", [Margin],
    [Revenue]
)

Field parameters are usually cleaner for visual binding; SWITCH is better when one measure must feed many visuals consistently.

What-if / threshold
Modeling → New parameter (numeric). Reference ParameterTable[ParameterValue] in measures for targets, banding, or scenario math.

Layout / mode parameters
Storyboard the modes as bookmarks (or pages). Do not try to recreate Tableau’s sheet-swapping parameter with a single DAX trick.

3. Wire titles and UX

Tableau dynamic titles that embed parameter values become:

Visual titles bound to field parameters, or
Card visuals / measures that return SELECTEDVALUE(...) text

Train authors: Power BI’s filter pane and sync slicers replace a lot of “parameter + apply to all sheets” patterns.

4. Validate behavior, not just values

Same default as Tableau on first open
Single-select vs multi-select parity
Whether “All” is allowed
Interactions with other slicers (edit interactions)
Mobile layout: field parameters and bookmarks can be awkward on phone—test early

Common pitfalls

One mega-parameter that filtered and switched metrics and changed layout
Translating list parameters into what-if parameters
Forgetting calculations that referenced the parameter only inside LOD or table calcs
Bookmarks that capture unintended filter state

Checklist

[ ] Full parameter inventory with references and intent
[ ] Standard patterns agreed (slicer / field param / what-if / bookmark)
[ ] Shared metric-switcher approach for the program, not one-off per report
[ ] Titles and defaults verified
[ ] Interaction and mobile checks complete