What-If Parameters in Power BI - Scenario Modelling Without Excel
Every finance team I've worked with has a scenario model in Excel. It's usually built on top of a pivot table, with a few input cells coloured yellow, and the analyst who built it five years ago has long since left the business. When someone asks "what would our revenue look like if we discounted by 12 percent instead of 10?", the answer involves opening that spreadsheet, finding the right cell, and hoping nothing breaks.
Power BI's what-if parameters solve this problem. They give you a slider on a report page that report consumers can move around, and the visuals update in real time based on whatever value they've selected. It's the kind of feature that makes the difference between a static dashboard and an actual decision-support tool.
I've been using what-if parameters with clients since they were introduced, and they're one of the most underrated features in Power BI Desktop. Here's how they work, where they genuinely add value, and the situations where they'll trip you up.
What a What-If Parameter Actually Is
A what-if parameter in Power BI is a numeric range with a name. You define the minimum value, maximum value, and the increment between each step. Power BI creates two things behind the scenes: a calculated table containing all the possible values, and a measure that returns the currently selected value.
You access it through the Modeling tab in Power BI Desktop. Click "New parameter", choose Numeric range (Fields is the other option, but we'll come back to that), and fill in a dialog. Name, data type, minimum, maximum, increment. There's also a checkbox to add a slicer to the current page, which you'll almost always want.
A worked example. You're modelling discount impact. Name the parameter Discount percentage. Set the data type to Decimal number. Minimum 0, maximum 0.50, increment 0.05. That gives you a slider that moves between 0% and 50% in 5% steps. Power BI builds the underlying table, the measure that returns the selected value, and (if you ticked the box) drops a slicer onto your canvas.
One thing the documentation calls out and I'll repeat because people get caught by it: for decimal numbers, you must enter values with a leading zero. Type 0.50, not .50. If you type .50, Power BI won't validate the input and the Create button stays greyed out. Small thing, but I've watched people stare at the dialog for five minutes trying to work out why it won't let them continue.
Building the Measure That Uses the Parameter
The parameter on its own doesn't do anything useful. You need a measure that references it.
Going back to the discount example, the measure looks like this:
Sales after Discount = SUM(Sales[SalesAmount]) - (SUM(Sales[SalesAmount]) * 'Discount percentage' [Discount percentage Value])
The pattern is straightforward. You're taking your sales amount, multiplying it by the parameter value (which represents the discount), and subtracting that from the total. The result is what sales would look like if that discount applied across the board.
Drop the original SalesAmount and the new Sales after Discount measure onto a column chart with OrderDate on the x-axis. Move the slider. Both columns are visible side by side, but only the Sales after Discount column changes as the slider moves. You can see the impact of every discount percentage from 0% to 50% in real time.
This is where the feature earns its keep. Compared to building the same scenario in Excel, you've gained interactivity, sharing through Power BI Service, and the ability for non-technical stakeholders to play with the values without breaking anything.
Where What-If Parameters Genuinely Help
I'll be honest about where I've seen real value from these in client work, because the marketing copy makes them sound more universally useful than they are.
Discount and margin modelling. Sales leaders want to understand the revenue impact of pricing decisions. A what-if parameter on discount percentage, multiplied through a sales model, lets them see exactly what a percentage point of margin is worth across product lines and customer segments. This is probably the most common use case we see.
Commission and incentive scenarios. Sales operations teams use these to model what their team's compensation looks like under different commission structures. Slide the commission rate up or down, see how it changes the payout against actual or forecasted sales. Useful during incentive plan reviews.
Capacity and resource planning. Manufacturing and services businesses use what-if parameters for capacity scenarios. What if we add 2 more crew? What if utilisation improves by 5%? The interactivity makes these conversations productive in a way that static reports don't.
Sensitivity analysis on forecasts. Finance teams use parameters to show how forecasts shift when key drivers change - FX rates, input costs, growth assumptions. Instead of running 12 different versions of a forecast, you build one model with parameter-driven inputs and let stakeholders explore the sensitivity themselves.
The common thread in all of these is that the parameter represents a single variable that flows through to multiple visuals. If your scenario only affects one number on one visual, you probably don't need a parameter. A regular measure is fine.
The Fields Option Worth Knowing About
The dialog also offers Fields as a parameter type, which gets less attention than the numeric range option but is genuinely useful.
A Fields parameter lets the user pick which measure or dimension is being used in a visual. Build a chart that shows revenue, and configure the parameter so the user can switch between revenue, units, margin, and contribution by clicking different buttons or moving a slicer.
This is a clean way to fit more analysis into less screen space. Instead of building four separate charts (one for each metric), you build one chart and let the user choose what's displayed. For executive dashboards where real estate matters, this is a useful pattern.
The implementation pattern is the same. New parameter, choose Fields, drag the measures you want available into the dialog. Power BI creates the parameter and (optionally) a slicer.
What to Watch Out For
A few real limitations and gotchas worth flagging before you build something you'll regret.
The 1,000-value limit. Parameters can have at most 1,000 unique values. If your minimum, maximum, and increment combine to produce more than that, Power BI samples the values evenly, which can result in odd-looking sliders that skip values. Keep the math sensible. A discount slider from 0 to 0.50 in 0.05 increments produces 11 values. A salary slider from 50,000 to 500,000 in 100 increments produces 4,501 values, which will get sampled. Adjust the increment so you stay under 1,000.
Parameters are designed for measures within visuals. This is in the documentation but it's easy to miss. If you try to use a parameter value in a dimension calculation, the result can be wrong. The parameter is fundamentally a slicer-driven scalar value, and DAX evaluates it in the filter context of the visual. Putting it in places where it doesn't belong causes incorrect calculations that don't always throw an error - they just produce wrong numbers, which is the worst kind of bug.
One parameter, one purpose. It's tempting to build elaborate parameter systems where one slider controls multiple measures. This usually works fine, but it makes maintenance harder. If you find yourself needing five interrelated parameters, you've probably crossed the line into the territory where you should be modelling the scenario differently - maybe in a separate calculated table or through DAX functions like SWITCH.
The slicer styling is dated. The default what-if slicer looks like a 2018 web form. You can change it to a numeric range slicer, dropdown, or list, but none of them look great. If you care about the visual polish of your report (and you should), expect to spend time getting the slicer to look acceptable. Sometimes the cleanest answer is to use a custom visual for the input.
A Pattern That Works Well
The setup I recommend to clients is this. Build the parameter. Build the measure that uses the parameter. Build a small visual that just shows the current parameter value clearly, somewhere prominent on the page. Then build your main visuals using the measure.
The reason for the "show the current value" visual is that users get confused about what the slider is doing. Showing the value in a card visual next to the slider, or in a callout, makes it obvious. "Discount: 15%" displayed in big text near the slider eliminates a class of support questions.
This is also a place where good parameter naming matters. The auto-generated measure is called something like "Discount percentage Value", which is fine in the DAX editor but ugly when it appears in tooltips or visuals. Rename it to something readable. "Discount Rate" beats "Discount percentage Value" every time.
Where This Fits Into a Wider Power BI Practice
What-if parameters are one of the features that separates a Power BI report from a Power BI application. Reports show you what happened. Applications let you explore what could happen. The shift from one to the other is where Power BI starts to compete with bespoke planning tools.
We work with finance and operations teams on this kind of work through our Power BI consulting practice, and the pattern that consistently produces value is taking an existing static report and adding two or three parameters that let stakeholders explore the assumptions underneath it. A discount slider on the sales dashboard. A growth rate parameter on the forecast page. A capacity parameter on the operational view. None of these are expensive to build, and each one shifts the conversation from "here's what happened" to "what should we do".
For broader work on building decision-support tools rather than reporting dashboards, our AI for business intelligence practice covers the patterns we use to combine parametric modelling with AI-driven insights and recommendations. That's increasingly where the high-value work in Power BI sits.
The what-if parameter is a small feature with disproportionate value. If your reports don't use them, your reports are probably less useful to decision-makers than they could be.
Reference: Create and use parameters to visualize variables in Power BI Desktop (Microsoft Learn)