Co-authored by

What Are Power BI Field Parameters and Why Do They Matter?

Quick answer: Field parameters are calculated tables that let report readers dynamically swap the measures or dimensions displayed in a visual — replacing the old SWITCH/SELECTEDVALUE workaround with a native, supported feature that became generally available in July 2025.

Before field parameters existed, the standard approach for letting users toggle between measures was a disconnected table, a slicer, and a DAX measure built around SWITCH( SELECTEDVALUE(...), ... ). It worked, but it was fragile: every new measure required editing the SWITCH expression, conditional formatting had to be wired up manually, and the visual always showed one generic column header regardless of what the user selected.

Field parameters solve all of that. When a user picks "Revenue" from a slicer, the visual does not evaluate a SWITCH measure — it queries the actual [Revenue] measure directly. Column headers update automatically, formatting follows the underlying measure, and the report author never touches a SWITCH expression again.

Since reaching general availability in the July 2025 Power BI Desktop update, field parameters are fully supported for production use. The GA release also introduced hierarchy persistence in matrix visuals — a significant quality-of-life improvement covered later in this guide.

This post walks through everything you need to build dynamic reports with field parameters: creating them via the UI and via DAX, measure parameters, dimension parameters, integration with calculation groups, the SELECTEDVALUE gotcha, and the full list of current limitations. If you are new to DAX, our CALCULATE function guide covers the foundational concepts that underpin many patterns discussed here. For interactive scenario modelling with numeric sliders rather than field switching, see our what-if parameters guide.

How Do You Create a Field Parameter in Power BI Desktop?

Quick answer: Go to the Modeling tab, select New parameter > Fields, choose the measures or columns you want, and Power BI generates a calculated table, a slicer, and the necessary metadata automatically.

The Microsoft Learn documentation for field parameters outlines the process in four steps:

1. Open the Modeling tab in Power BI Desktop and select New parameter > Fields.
2. Give the parameter a name (for example, Metric Selector) and select the fields — measures, columns, or a mix of both.
3. Drag to reorder fields or double-click to rename the display labels.
4. Leave the "Add slicer to this page" checkbox enabled, then click Create.

Power BI generates three things behind the scenes:

• A calculated table using DAX with the NAMEOF function.
• A slicer on the current page, pre-bound to the parameter.
• Metadata properties (ParameterMetadata and GroupByColumns) that tell the engine this table is a field parameter, not an ordinary table.

Once created, drag the parameter into the field wells of any visual — Axis, Legend, Values — wherever you would normally place a column or measure. The slicer controls which field the visual actually queries.

The Generated DAX

When you create a parameter named Metric Selector with three measures, Power BI writes something like this:

Metric Selector = {
    ("Revenue", NAMEOF('Sales'[Revenue]), 0),
    ("Gross Margin", NAMEOF('Sales'[Gross Margin]), 1),
    ("Units Sold", NAMEOF('Sales'[Units Sold]), 2)
}

Each row is a tuple of three values:

You can edit this DAX directly to add fields, remove fields, or change display names. Press Shift + Enter inside the formula bar to add new rows, and separate each tuple with a comma.

How Do Measure Parameters Work?

Quick answer: A measure parameter lets users switch which measure a visual evaluates — Revenue, Margin, Units Sold — without the report author writing any SWITCH logic. The visual queries the selected measure directly.

Measure parameters are the most common use case. Instead of building a single "dynamic measure" that internally branches on a slicer value, you list real measures in the parameter table and let the engine handle the switching.

Step-by-Step Example

Suppose you have three measures already defined:

Revenue = SUM( Sales[Sales Amount] )
Gross Margin = SUM( Sales[Sales Amount] ) - SUM( Sales[Total Cost] )
Units Sold = SUM( Sales[Quantity] )

Create a field parameter called KPI Selector using the UI or write the DAX manually:

KPI Selector = {
    ("Revenue", NAMEOF('Sales'[Revenue]), 0),
    ("Gross Margin", NAMEOF('Sales'[Gross Margin]), 1),
    ("Units Sold", NAMEOF('Sales'[Units Sold]), 2)
}

Now place KPI Selector in the Values well of a bar chart and a dimension like Product[Category] on the axis. When a user selects "Gross Margin" from the slicer, the bar chart queries [Gross Margin] directly — the column header updates, the number format follows the measure definition, and conditional formatting rules tied to that measure apply automatically.

Why This Beats the SWITCH Pattern

The old approach looked like this:

Selected KPI =
SWITCH(
    SELECTEDVALUE( 'KPI Table'[KPI Name] ),
    "Revenue", [Revenue],
    "Gross Margin", [Gross Margin],
    "Units Sold", [Units Sold],
    BLANK()
)

That pattern has three problems: the column header always says "Selected KPI" regardless of which measure is active, number formatting cannot adapt per measure, and every new KPI requires editing the SWITCH expression. Field parameters eliminate all three issues because the visual directly references the underlying measure.

How Do Dimension Parameters Work?

Quick answer: A dimension parameter lets users switch which column appears on an axis or in a matrix — toggling between Product, Category, Region, or any other dimension — so one visual serves multiple analytical perspectives.

Dimension parameters follow the same structure as measure parameters but reference columns instead of measures:

Slice By = {
    ("Category", NAMEOF('Product'[Category]), 0),
    ("Brand", NAMEOF('Product'[Brand]), 1),
    ("Country", NAMEOF('Customer'[Country]), 2),
    ("City", NAMEOF('Customer'[City]), 3)
}

Place Slice By on the axis of a bar chart and a measure in the Values well. Users can now switch the grouping dimension from a slicer without the report author duplicating visuals.

Mixed Parameters: Measures and Dimensions Together

You can combine measures and columns in a single parameter. This is useful for building fully dynamic tables where users control both the rows and the values. However, visuals that expect a specific field type (for example, the Values well of a chart expects a measure) will reject incompatible selections. Keep mixed parameters for table and matrix visuals where both types are valid in the same drop zone.

GCC Application: Reducing Page Count

Government and semi-government organisations across the GCC often report across multiple entities — departments, subsidiaries, regional offices. Without field parameters, report authors typically create one page per analytical dimension: a page grouped by department, another by cost centre, another by project code. A single dimension parameter can consolidate these into one page. For a ministry with ten reporting dimensions, that can reduce a fifty-page report to five pages while giving each stakeholder the flexibility to see their preferred view. If you are moving from spreadsheet-based reporting, our Excel to Power BI migration guide covers the broader transition path.

What Changed with GA in July 2025? Hierarchy Persistence Explained

Quick answer: The July 2025 GA release introduced hierarchy persistence — when a user changes the field parameter selection in a matrix, the matrix retains its expanded or collapsed state instead of snapping back to the top level.

Before July 2025, switching a field parameter in a matrix collapsed the entire hierarchy. If a user had drilled into Year > Quarter > Month and then changed the dimension parameter, the matrix reset to the top level. Users had to re-expand every time, which was frustrating in exploratory analysis.

With GA, the matrix now preserves its expansion state by default. Switch from Category to Brand, and the rows stay expanded to the same depth.

Controlling the Behaviour

Some report designs intentionally want the matrix to reset when the parameter changes. The January 2026 update added a toggle for this:

• Power BI Desktop: Options and settings > Options > Current File > Report settings > Field Parameters > Persist hierarchy level
• Fabric service: Report settings > Persist hierarchy level under Field parameter options

When enabled (the default), the matrix keeps its expanded state. When disabled, it reverts to the pre-July 2025 behaviour of collapsing to the top level on every parameter change.

How Do Field Parameters Work with Calculation Groups?

Quick answer: Field parameters handle simple measure switching natively, while calculation groups provide richer DAX logic per option — combining them enables advanced patterns like conditional formatting that adapts to the selected measure.

Calculation groups and field parameters overlap in functionality: both let users switch between calculated outputs. The key difference is flexibility. A field parameter points to existing measures and lets the engine switch between them. A calculation group wraps measures in DAX expressions — time intelligence variants, currency conversions, cumulative totals — and applies transformations dynamically.

When to Use Which

Advanced Pattern: Conditional Formatting by Selected Measure

A common requirement is to change the colour of a KPI card based on which measure is selected — green for margin above target, red for revenue below forecast. This requires detecting which measure the user selected.

With field parameters, you can detect the selection using MAX on the parameter's display column (not SELECTEDVALUE — more on that gotcha below):

KPI Color =
VAR CurrentMeasure = MAX( 'KPI Selector'[KPI Selector] )
VAR Result =
    SWITCH(
        CurrentMeasure,
        "Revenue", IF( [Revenue] > [Revenue Target], "Green", "Red" ),
        "Gross Margin", IF( [Gross Margin] > 0.3, "Green", "Red" ),
        "Units Sold", IF( [Units Sold] > 1000, "Green", "Red" )
    )
RETURN
    IF( COUNTROWS( 'KPI Selector' ) = 1, Result )

For more complex scenarios, SQLBI's guide on field parameters and calculation groups for conditional formatting walks through the full pattern, including using an intermediate disconnected table to bridge the two features.

What Is the SELECTEDVALUE Gotcha with Field Parameters?

Quick answer: You cannot use SELECTEDVALUE directly on a field parameter's display column because of a hidden Group By Columns property — use MAX for single-selection scenarios or the SUMMARIZE + SELECTCOLUMNS workaround for robust detection.

This is the most common stumbling block when developers try to build DAX logic that reacts to the field parameter selection. The parameter table's display column has a Group By Columns property linking it to the hidden fields column. This creates a composite key that causes SELECTEDVALUE (and HASONEVALUE) to fail with a calculation error.

The Error

If you write:

Selected = SELECTEDVALUE( 'KPI Selector'[KPI Selector] )

You get: "Column [KPI Selector] is part of composite key, but not all columns of the composite key are included in the expression."

Workaround 1: Use MAX (Simplest)

If the slicer is set to single-select, MAX returns the one selected value without triggering the composite key error:

Selected Measure Name = MAX( 'KPI Selector'[KPI Selector] )

This works for most conditional formatting and branching scenarios. Wrap it in an IF( COUNTROWS( 'KPI Selector' ) = 1, ... ) guard if you need to handle multi-select gracefully.

Workaround 2: SUMMARIZE + SELECTCOLUMNS (Robust)

For scenarios where you need a true single-value check that respects multi-select, SQLBI recommends this pattern:

VAR __SelectedValue =
    SELECTCOLUMNS(
        SUMMARIZE(
            'KPI Selector',
            'KPI Selector'[KPI Selector],
            'KPI Selector'[KPI Selector Fields]
        ),
        'KPI Selector'[KPI Selector]
    )
RETURN
    IF( COUNTROWS( __SelectedValue ) = 1, __SelectedValue )

This explicitly includes both columns of the composite key in the SUMMARIZE, then projects back to just the display column. It returns BLANK() if multiple items are selected.

Workaround 3: Add a Calculated Column

Add a calculated column to the parameter table that copies the display column:

KPI Name = 'KPI Selector'[KPI Selector]

The new column does not inherit the Group By Columns property, so SELECTEDVALUE( 'KPI Selector'[KPI Name] ) works normally. This is the simplest structural fix but adds a column to the model.

What Are the Known Limitations of Field Parameters?

Quick answer: Field parameters do not work with Analyze in Excel, Q&A visuals, live connections without a local model, implicit measures, or drill-through page linking — and there is no "none selected" option for slicers.

The Microsoft Learn documentation lists these limitations as of early 2026:

Copilot Interaction

When using field parameters with Copilot in Power BI, Copilot responds based on the current state of the visuals — meaning the currently selected parameter value. It does not enumerate all possible parameter states.

How Do You Write Field Parameter DAX Manually?

Quick answer: Define a calculated table using row constructors with three columns per field — display name, NAMEOF reference, and sort order — then apply the ParameterMetadata extended property via Tabular Editor or the UI.

While the UI is the fastest way to create field parameters, manual DAX gives you full control — useful when scripting deployments, using Tabular Editor, or adding parameters to ALM pipelines.

Basic Measure Parameter

Financial Metrics = {
    ("Revenue", NAMEOF('Sales'[Revenue]), 0),
    ("Cost of Goods Sold", NAMEOF('Sales'[COGS]), 1),
    ("Gross Margin", NAMEOF('Sales'[Gross Margin]), 2),
    ("Net Profit", NAMEOF('Sales'[Net Profit]), 3)
}

Basic Dimension Parameter

Grouping Dimension = {
    ("Department", NAMEOF('Organisation'[Department]), 0),
    ("Cost Centre", NAMEOF('Organisation'[Cost Centre]), 1),
    ("Project", NAMEOF('Project'[Project Name]), 2),
    ("Region", NAMEOF('Geography'[Region]), 3)
}

Metadata Requirements

The DAX alone is not enough. Power BI needs two metadata properties to treat the table as a field parameter:

1. ParameterMetadata — An extended property on the hidden fields column that marks this table as a parameter table.
2. Group By Columns — A property linking the display column to the fields column, creating the composite key that enables the switching behaviour.

When you use the UI, these properties are set automatically. When creating parameters via Tabular Editor or the XMLA endpoint, you must set them manually. The SQLBI article on field parameters internals documents the exact property names and values.

Performance Note

Field parameters add minimal overhead. Each visual with a field parameter executes two queries instead of one: a metadata query to retrieve the selected column names, and the actual data query using those names. The metadata query is lightweight, so the performance impact is negligible even on complex reports.

Frequently Asked Questions

Q: Do field parameters replace the SWITCH/SELECTEDVALUE measure pattern entirely?

For simple measure switching — letting users toggle between Revenue, Margin, and Units — yes. Field parameters are the recommended approach since GA in July 2025. The SWITCH pattern is still useful when you need to apply custom DAX logic per selection (for example, different number formats or entirely different calculation logic per option), but for straightforward switching, field parameters are cleaner, more maintainable, and provide automatic header and format updates.

Q: Can I use field parameters with DirectQuery models?

Yes, but with a caveat. You cannot create field parameters in a pure live connection to a remote semantic model or Analysis Services instance. However, if you enable DirectQuery for Power BI semantic models and add a local model (creating a composite model), field parameters work normally. The parameter table itself is always local — it is a calculated table in the report's model layer.

Q: Why does SELECTEDVALUE fail on field parameter columns?

The display column in a field parameter table has a hidden Group By Columns property that creates a composite key with the fields column. SELECTEDVALUE internally relies on HASONEVALUE, which cannot evaluate columns that are part of a composite key. The workaround is to use MAX for single-select scenarios, or the SUMMARIZE + SELECTCOLUMNS pattern documented by SQLBI for robust multi-select handling.

Q: Do field parameters work with Analyze in Excel?

No. Analyze in Excel uses MDX to query the Power BI semantic model, and MDX is not aware of field parameters. This is currently one of the most significant limitations. If your organisation depends on Excel-connected PivotTables for ad-hoc analysis, field parameters in the underlying model will not be available to those Excel users. Consider providing a dedicated Excel-friendly report view with explicit measures instead.

Q: Can I mix measures and dimensions in one field parameter?

Yes. Power BI allows measures and columns in the same parameter table. This is useful for fully dynamic table or matrix visuals where users control both the grouping and the values. However, visuals with type-specific field wells (for example, a chart's Values well expects measures) will reject incompatible selections. For most production reports, keeping measure parameters and dimension parameters separate avoids confusing end users.

Q: How do field parameters interact with row-level security?

Field parameters do not interfere with RLS. Because the parameter table only contains display names and metadata references — not actual data — RLS filters on the underlying tables apply normally. When a user selects a dimension through a field parameter, the visual queries the actual column, and any RLS rules on that column's table are enforced. The parameter table itself does not need RLS rules.

Q: What is hierarchy persistence and can I turn it off?

Hierarchy persistence, introduced with the July 2025 GA release, means that a matrix visual retains its expanded or collapsed state when the user changes the field parameter selection. Previously, the matrix always collapsed to the top level. You can disable this behaviour in Power BI Desktop via Options > Current File > Report settings > Field Parameters > Persist hierarchy level. In the Fabric service, find the same toggle in the report settings. Disabling it restores the pre-July 2025 collapse-on-change behaviour.

Q: How many fields can a single parameter contain?

There is no documented hard limit on the number of fields in a parameter, but practical usability sets the boundary. A slicer with more than ten to fifteen options becomes difficult for users to navigate. For large field lists, consider grouping related fields into separate parameters (one for financial measures, one for operational measures) or using a dropdown slicer style instead of buttons.

Q: Can I use field parameters in paginated reports or Power BI Report Server?

Field parameters are a Power BI Desktop and Power BI service feature. They are not supported in paginated reports (which use RDL, not the Power BI visual layer) or in Power BI Report Server on-premises deployments. For organisations running Power BI Report Server on-premises, the SWITCH/SELECTEDVALUE pattern remains the only option for dynamic measure switching.