A parameter's suggested default and its stored value can legitimately differ. If a query selects the wrong region, inspect the value actually passed to its transformation before changing the source records. A reassuring dropdown list is not proof that the current argument is one of its suggestions.

Prepare a small Power Query practice table with two East records and one West record. Keep their identifiers visible. In Power BI Desktop's Power Query Editor, open Home, Manage Parameters and create a Text parameter called ChosenRegion with suggested values East and West.

Distinguish the fields in the parameter dialog

Set Default Value to East and Current Value to West. Microsoft defines Current Value as the stored value used by transformations; Default Value is the suggested default shown when referencing the parameter. The suggested list is advisory: another value can still be entered manually.

Use the parameter in a row-selection step. For a preceding step called Source whose table contains a Region column, the following M expression retains matching rows:

Table.SelectRows(Source, each [Region] = ChosenRegion)

Table.SelectRows returns rows meeting its condition. In this expression, ChosenRegion refers to the parameter. Quoting it as "ChosenRegion" would instead compare against that literal text. Preserve the actual preceding step name when adapting the example to an existing query.

Expect only the West record while Current Value is West, even though Default Value says East. Read the surviving identifier, not merely the row count. Then set Current Value to East and confirm the two East identifiers in the preview.

Test a value outside the suggestions

In the practice copy, enter North as Current Value while leaving the suggested list unchanged. With no North source records, the equality condition should return no rows. This demonstrates the distinction between a convenient list of suggestions and a rule that rejects every unlisted value.

Restore the intended Current Value after the experiment. If the real process must restrict input to approved regions, establish a separate validation or error rule rather than assuming this list supplies one. An empty result can be legitimate, but it should not silently pass when the workflow requires records.

Record the parameter's type, current setting and purpose with the query handover. Inspect the applied expression as well: a hard-coded region string would ignore the parameter entirely. Acceptance requires the stored argument, the transformation and the selected record identities to agree, without treating a displayed default as evidence of what the query used.

Sources: Microsoft: query parameters; Microsoft: supporting procedure.