Parameters and query reuse

What it does

A parameter is a named, typed value you define once and reference from any query step or custom function. Combined with referenced queries and custom functions, parameters are how you stop copying the same logic into six places and how you make one file deployable across dev, test and production.

Key facts

Parameter properties are Name, Description, Required, Type, Suggested Values and Current Value. Suggested Values can be Any value, a fixed List of values, or a Query returning a list.
With a List of values you also get a Default Value, which is separate from the Current Value. Default is what's offered to whoever supplies the parameter; Current is what's actually stored and passed.
Any query whose result is a simple constant can be turned into a parameter with right-click > Convert to Parameter, and back again with Convert To Query.
To use a parameter as a step argument in the UI you need View > Parameters > Always allow switched on first. Without it the Parameter option doesn't appear in filter dialogs.
Right-click a query > Create Function turns it into a custom function, with any parameters it references becoming the function's arguments.
Multi-value list parameters are Power Query Online only. They work with the In and Not in filter operators.
Microsoft's own guidance is that referenced queries avoid duplicated logic but can slow refresh and hammer the source, because Power Query evaluates each referencing query separately with the referenced steps embedded — there's no shared cached result.

When to use / skip

Parameterise anything that changes between environments — server name, database name, file path, API root — and anything that changes with time, like a history cut-off date. That's the whole payback: one file, three environments, no hand-editing M at deployment. Custom functions earn their keep when the same shape of transformation applies to many things, most commonly the "combine files from a folder" pattern. Where people go wrong is reference chains: referencing a query feels like reuse but Power Query re-runs the upstream steps for every consumer, so a tidy-looking chain can multiply your source hits. If you want genuine "compute once, reuse many", that's a dataflow, not a referenced query.

Configuration decisions

Which values are genuinely environment-specific and belong in parameters, versus values that just look configurable.
Whether parameter values get set in the Power BI service after publish, or bound to a deployment pipeline rule.
Suggested Values type per parameter — a free-text server name invites typos; a list of three doesn't.
Reference versus duplicate: reference for shared logic you want maintained in one place, duplicate when you deliberately want the branches to diverge and stay independent.
Whether repeated logic warrants a custom function, a dataflow, or leaving it alone.
Which intermediate queries have Enable load turned off so they stay as staging queries and don't become model tables.

Gotchas

Duplicate copies the query including its whole step history. It doesn't copy the source data or share anything afterwards — the two copies drift the moment someone edits one.
Reference doesn't cache. Five queries referencing one staging query means five evaluations against the source, not one. This surprises people who expect it to behave like a view.
Parameter values are stored with the file. Publish a .pbix with dev parameter values and you've published a report pointing at dev.
Data type on a parameter matters more than it looks — an untyped parameter passed into a filter can produce type mismatch errors that surface several steps later.
Custom functions created from a query keep referencing the parameters, so changing a parameter's Current Value changes the function's default behaviour too.

Consultant notes

Parameterise the connection before the first publish, not after. Retrofitting it once reports are live means republishing everything.
If the client has deployment pipelines, wire parameters to pipeline rules and demo it. It's the single most convincing "this is a proper delivery process" moment in a Power BI engagement.
When you see a long reference chain in a client's file, check refresh duration and source load before praising the design. Microsoft's own guidance points at dataflows as the fix.
Document what each parameter is for in the Description field. It's the only documentation that travels with the file.

Worth revisiting when the client adopts deployment pipelines, or if multi-value parameters land in Desktop.