Power Query Parameters: The Complete Guide to Dynamic Data Sources in Power BI

1. What Are Power Query Parameters

Power Query parameters are named variables in the M language that store values you can reference across multiple queries. Instead of hardcoding a server name like "sql-prod-01.company.com" directly into your data source connection, you create a parameter called ServerName and reference it wherever you need that value. Change the parameter once, and every query that references it updates automatically.

Parameters vs. Other Power BI “Parameter” Types

Power BI has three things called “parameters,” and they are frequently confused. Understanding the differences is critical before you build anything.

Supported Parameter Types

Power Query parameters support the following data types. Choosing the correct type matters because it determines how the value is passed to your data source and whether query folding can occur.

• Text — The most common type. Used for server names, database names, file paths, API endpoints, schema names. Stored as a string in M.
• Decimal Number — Used for numeric thresholds, page numbers, batch sizes. Passed as a number type in M.
• Date/Time — Required for RangeStart and RangeEnd incremental refresh parameters. Also useful for report date filters applied at source.
• Date — A date without time component. Less common but useful for daily partition boundaries.
• True/False — Boolean parameters for toggling query logic. Example: a IncludeArchived flag that controls whether archived records are loaded.
• Any — Accepts any data type. Use sparingly — it bypasses type validation and can cause unexpected behavior in production.
• Duration — Time spans. Rarely used in practice but available for specialized time-based calculations.
• Binary — Raw binary data. Almost never used as a parameter type in practice.

For enterprise deployments, I recommend limiting parameters to Text, Decimal Number, and Date/Time. These three types cover 99% of real-world use cases and are fully supported by deployment pipeline parameter rules.

2. Creating Parameters Step-by-Step

There are two ways to create Power Query parameters: through the Manage Parameters dialog (recommended for most users) or by writing M code directly in the Advanced Editor. Here is the standard approach using the dialog.

Using the Manage Parameters Dialog

1. Open Power Query Editor.In Power BI Desktop, go to Home > Transform data. This opens the Power Query Editor window.
2. Click Manage Parameters > New Parameter.In the Power Query Editor ribbon, click the “Manage Parameters” dropdown and select “New Parameter.” The Manage Parameters dialog opens.
3. Configure the parameter:
   • Name: Use PascalCase with no spaces (e.g., ServerName, DatabaseName, FilePath). Avoid spaces — they cause issues in M code references.
   • Description: Document what the parameter controls. This shows up in deployment pipeline settings and helps other developers.
   • Required: Check this box. Optional parameters that are empty at refresh time cause cryptic M errors.
   • Type: Select the appropriate type (Text for connection strings, Date/Time for date filters).
   • Suggested Values: Choose “List of values” to provide a dropdown of allowed values. This prevents typos and makes it clear which values are valid. For example, a ServerName parameter might have sql-dev-01.company.com, sql-test-01.company.com, and sql-prod-01.company.com as allowed values.
   • Default Value: The fallback value if no current value is specified. Set this to your development environment value.
   • Current Value: The value Power BI uses right now when it runs queries. This is what you change when you switch environments locally.
4. Click OK.The parameter appears in the Queries pane on the left side, listed under a “Parameters” group.
5. Reference the parameter in your queries. Open any query in the Advanced Editor and replace hardcoded values with the parameter name. For example, replace "sql-prod-01.company.com" with ServerName.

Creating a Parameter in M Code Directly

You can also create parameters by writing M code in a blank query. This approach is useful when you need to script parameter creation or when you want more control over metadata.

// Create a parameter named ServerName
"sql-dev-01.company.com" meta [
    IsParameterQuery = true,
    IsParameterQueryRequired = true,
    Type = "Text",
    Description = "SQL Server hostname for the target environment",
    DefaultValue = "sql-dev-01.company.com",
    AllowedValues = {
        "sql-dev-01.company.com",
        "sql-test-01.company.com",
        "sql-prod-01.company.com"
    }
]

The meta record is what tells Power Query this is a parameter, not just a regular query that returns a text value. The IsParameterQuery = true flag is required. Without it, the query appears as a regular query in the editor and cannot be used with deployment pipeline parameter rules.

Binding Parameters to Data Source Settings

After creating parameters, you need to bind them to your data source connections. The easiest way is to right-click on a data source step in the Applied Steps pane, select “Edit Settings,” and use the dropdown to select your parameter instead of typing a literal value. This works for SQL Server connections, file paths, web URLs, and most other connector types. Once bound, changing the parameter value automatically updates the connection.

3. Five Enterprise Use Cases with Code

These are the five parameter patterns I implement most frequently in enterprise Power BI consulting engagements. Each includes production-ready M code you can adapt to your environment.

Use Case 1: Dev/Test/Prod Environment Switching

This is the single most important parameter pattern for enterprise Power BI. Every organization with more than one environment needs this. You create parameters for the server name, database name, and optionally the schema name. When a developer works locally, the parameters point to the development server. When the report is deployed through a pipeline, the parameter values are automatically overwritten to match each stage.

// Parameters (defined as separate queries)
// ServerName = "sql-dev-01.company.com"
// DatabaseName = "SalesDB_Dev"

let
    Source = Sql.Database(ServerName, DatabaseName, [
        Query = "
            SELECT
                o.OrderID,
                o.OrderDate,
                o.CustomerID,
                o.TotalAmount,
                c.CustomerName,
                c.Region
            FROM Sales.Orders o
            INNER JOIN Sales.Customers c
                ON o.CustomerID = c.CustomerID
            WHERE o.OrderDate >= DATEADD(YEAR, -2, GETDATE())
        "
    ]),
    #"Set Column Types" = Table.TransformColumnTypes(Source, {
        {"OrderID", Int64.Type},
        {"OrderDate", type datetime},
        {"CustomerID", Int64.Type},
        {"TotalAmount", Currency.Type},
        {"CustomerName", type text},
        {"Region", type text}
    })
in
    #"Set Column Types"

When you promote this report through a deployment pipeline, the parameter rules automatically change ServerName to sql-test-01.company.com in Test and sql-prod-01.company.com in Production. No manual edits. No risk of accidentally refreshing against the wrong server.

Use Case 2: Multi-Tenant Data Isolation

In multi-tenant SaaS environments or organizations with multiple business units that share a database, you use a parameter to filter data at the source. This is different from row-level security (RLS), which filters after data is loaded into the model. Parameter-based filtering reduces the data volume before it enters Power BI, which improves refresh performance and reduces memory consumption.

// Parameter: TenantID = "TENANT_042"

let
    Source = Sql.Database(ServerName, DatabaseName),
    Sales_Transactions = Source{[Schema="dbo", Item="Transactions"]}[Data],
    #"Filtered by Tenant" = Table.SelectRows(
        Sales_Transactions,
        each [TenantID] = TenantID
    ),
    #"Removed TenantID Column" = Table.RemoveColumns(
        #"Filtered by Tenant",
        {"TenantID"}
    ),
    #"Set Types" = Table.TransformColumnTypes(
        #"Removed TenantID Column", {
            {"TransactionDate", type datetime},
            {"Amount", Currency.Type},
            {"ProductID", Int64.Type}
        }
    )
in
    #"Set Types"

This pattern works best when the TenantID column is indexed in the source database. The Table.SelectRows step folds to a WHERE TenantID = 'TENANT_042'clause in SQL, so only that tenant's data is ever transferred over the network. Each tenant gets their own workspace with their own parameter value, and deployment pipelines handle the promotion.

Use Case 3: Incremental Refresh Configuration

Incremental refresh is Power BI's mechanism for loading only new or changed data instead of reloading the entire table on every refresh. It relies on two special Power Query parameters: RangeStart and RangeEnd. These must be Date/Time type parameters with those exact names.

// Parameters (automatically managed by Power BI during refresh):
// RangeStart = #datetime(2024, 1, 1, 0, 0, 0)  type datetime
// RangeEnd   = #datetime(2026, 3, 26, 0, 0, 0)  type datetime

let
    Source = Sql.Database(ServerName, DatabaseName),
    Sales_Facts = Source{[Schema="dbo", Item="FactSales"]}[Data],
    #"Filtered Date Range" = Table.SelectRows(
        Sales_Facts,
        each [OrderDateTime] >= RangeStart
            and [OrderDateTime] < RangeEnd
    ),
    #"Set Types" = Table.TransformColumnTypes(
        #"Filtered Date Range", {
            {"OrderDateTime", type datetime},
            {"SalesAmount", Currency.Type},
            {"Quantity", Int64.Type},
            {"ProductKey", Int64.Type},
            {"CustomerKey", Int64.Type}
        }
    )
in
    #"Set Types"

The critical detail is that the filter step must support query folding. If query folding breaks (for example, because you applied a transformation before the filter that prevents folding), Power BI loads the entire table into memory and filters locally — which defeats the entire purpose. Always verify folding by right-clicking the filter step and checking if “View Native Query” is available. If it is grayed out, folding has broken and you need to restructure your query.

Use Case 4: Dynamic File Path for Scheduled Reports

Organizations that receive data files on a schedule (daily CSV exports, monthly Excel reports from vendors) can use parameters to point to the correct file location. This is especially common in healthcare and finance where data arrives from external systems that do not support direct database connections.

// Parameters:
// FileBasePath = "\\fileserver\data\sales\"
// FileName     = "daily_extract_20260326.csv"

let
    FullPath = FileBasePath & FileName,
    Source = Csv.Document(
        File.Contents(FullPath),
        [
            Delimiter = ",",
            Columns = 8,
            Encoding = 65001,
            QuoteStyle = QuoteStyle.Csv
        ]
    ),
    #"Promoted Headers" = Table.PromoteHeaders(Source, [PromoteAllScalars=true]),
    #"Set Types" = Table.TransformColumnTypes(
        #"Promoted Headers", {
            {"Date", type date},
            {"ProductCode", type text},
            {"Quantity", Int64.Type},
            {"UnitPrice", Currency.Type},
            {"Region", type text},
            {"SalesRepID", type text},
            {"Channel", type text},
            {"OrderID", type text}
        }
    )
in
    #"Set Types"

In the Power BI Service, this pattern requires an on-premises data gateway configured with the file path as a data source. The gateway must have read access to the file share. For cloud-based file storage, use SharePoint or OneDrive connectors with parameters for the site URL and document library path.

Use Case 5: API Pagination with Page Number Parameter

REST APIs that return paginated results require you to increment a page number and aggregate all pages into a single table. A parameter controls the base URL and can also define the page size, while a recursive function handles the pagination logic.

// Parameters:
// BaseApiUrl = "https://api.company.com"
// ApiPageSize = 500

// Helper function: GetPage
// (pageNumber as number) as table =>
let
    GetPage = (pageNumber as number) as table =>
        let
            Url = BaseApiUrl & "/api/v2/transactions",
            Response = Web.Contents(Url, [
                Headers = [
                    #"Accept" = "application/json",
                    #"Authorization" = "Bearer " & ApiToken
                ],
                RelativePath = "",
                Query = [
                    page = Number.ToText(pageNumber),
                    pageSize = Number.ToText(ApiPageSize)
                ]
            ]),
            JsonResponse = Json.Document(Response),
            DataTable = Table.FromRecords(JsonResponse[data])
        in
            DataTable,

    // Recursive pagination: get all pages
    GetAllPages = (page as number, accumulated as table) as table =>
        let
            CurrentPage = GetPage(page),
            Combined = Table.Combine({accumulated, CurrentPage}),
            Result = if Table.RowCount(CurrentPage) < ApiPageSize
                     then Combined
                     else @GetAllPages(page + 1, Combined)
        in
            Result,

    EmptyTable = #table(
        {"TransactionID", "Date", "Amount", "CustomerID"},
        {}
    ),
    AllData = GetAllPages(1, EmptyTable)
in
    AllData

Notice the use of Web.Contents with the Query record option instead of string concatenation for the URL. This is critical for Power BI Service compatibility. When you concatenate parameters directly into the URL string, the Service flags it as a “dynamic data source” and may block scheduled refresh. Using the Query option tells Power BI the base URL is static while the query parameters are dynamic, which is allowed.

4. M Language Parameter Patterns

Understanding how parameters work in M code is essential for building robust, production-ready queries. Here are the core patterns every Power BI architect should know.

Pattern 1: SQL Server with Server and Database Parameters

let
    Source = Sql.Database(ServerName, DatabaseName, [
        CreateNavigationProperties = false,
        CommandTimeout = #duration(0, 0, 10, 0)
    ]),
    dbo_FactSales = Source{[Schema="dbo", Item="FactSales"]}[Data]
in
    dbo_FactSales

The CreateNavigationProperties = false option improves performance by preventing Power Query from generating navigation columns for every table relationship. The CommandTimeout prevents long-running queries from hanging indefinitely.

Pattern 2: Web API with Base URL Parameter

// Parameter: BaseApiUrl = "https://api.company.com"
// Parameter: ApiVersion = "v3"

let
    Source = Web.Contents(
        BaseApiUrl,
        [
            RelativePath = "/api/" & ApiVersion & "/customers",
            Headers = [
                #"Accept" = "application/json",
                #"X-API-Version" = ApiVersion
            ],
            Query = [
                status = "active",
                limit = "1000"
            ]
        ]
    ),
    JsonResponse = Json.Document(Source),
    Customers = Table.FromRecords(JsonResponse[results]),
    #"Set Types" = Table.TransformColumnTypes(Customers, {
        {"id", Int64.Type},
        {"name", type text},
        {"email", type text},
        {"created_at", type datetimezone}
    })
in
    #"Set Types"

The key to avoiding the “dynamic data source” error is to pass the base URL as the first argument to Web.Contents() and use RelativePath for the variable parts. Power BI Service evaluates the first argument to determine the data source for gateway and credential binding. If the first argument is a parameter or expression, the Service cannot resolve it at design time and blocks the refresh.

Pattern 3: File Path Concatenation

// Parameter: DataDirectory = "D:\Reports\Monthly\"
// Parameter: ReportYear = "2026"
// Parameter: ReportMonth = "03"

let
    FilePath = DataDirectory
        & ReportYear & "\"
        & ReportMonth & "\"
        & "financial_summary.xlsx",
    Source = Excel.Workbook(File.Contents(FilePath), null, true),
    Sheet1 = Source{[Item="Summary", Kind="Sheet"]}[Data],
    #"Promoted Headers" = Table.PromoteHeaders(Sheet1, [PromoteAllScalars=true])
in
    #"Promoted Headers"

Pattern 4: Conditional Logic Based on Parameters

// Parameter: Environment = "Development"  (Text, List: Development, Test, Production)
// Parameter: IncludeTestData = true       (True/False)

let
    Source = Sql.Database(ServerName, DatabaseName),
    FactSales = Source{[Schema="dbo", Item="FactSales"]}[Data],
    #"Applied Environment Filter" =
        if Environment = "Production" then
            Table.SelectRows(FactSales, each [IsTestRecord] = false)
        else if IncludeTestData = true then
            FactSales
        else
            Table.SelectRows(FactSales, each [IsTestRecord] = false),
    #"Removed Test Flag" = Table.RemoveColumns(
        #"Applied Environment Filter",
        {"IsTestRecord"}
    )
in
    #"Removed Test Flag"

Be cautious with conditional logic in parameters. The if/then/else branches can break query folding depending on the data source. SQL Server handles this well because Power Query can fold both branches. Other connectors may not fold conditional logic, forcing a full data pull before the filter is applied.

Pattern 5: Schema Parameter for Multi-Schema Databases

// Parameter: SchemaName = "dbo"
// Useful when dev uses "dev_schema" and prod uses "dbo"

let
    Source = Sql.Database(ServerName, DatabaseName),
    TargetTable = Source{[Schema=SchemaName, Item="DimCustomer"]}[Data],
    #"Selected Columns" = Table.SelectColumns(TargetTable, {
        "CustomerKey",
        "CustomerName",
        "Email",
        "Region",
        "Segment",
        "CreatedDate"
    })
in
    #"Selected Columns"

5. Parameters and Deployment Pipelines

This is the enterprise differentiator that separates amateur Power BI deployments from production-grade ones. Power BI deployment pipelines let you define parameter rules that automatically override Power Query parameter values when content moves between stages. This means a developer never manually changes a connection string. The pipeline handles it.

How Deployment Pipeline Parameter Rules Work

1. You create a deployment pipeline in the Power BI Service with three stages: Development, Test, and Production. Each stage is backed by a separate workspace.
2. You assign workspaces to each stage. The Development workspace contains your actively developed reports and semantic models.
3. You configure parameter rulesfor each stage. Go to the pipeline > click the gear icon on the Test stage > Deployment Settings > select your semantic model > Parameter Rules. Add a rule for each parameter that needs to change between environments.
4. You deploy from Development to Test. The pipeline copies the content and automatically applies the parameter rules for the Test stage. The semantic model in the Test workspace now points to the test server without anyone manually editing anything.
5. You deploy from Test to Production. Same process. The Production parameter rules are applied. The semantic model now points to the production server.

Example Pipeline Configuration

Parameter Rules vs. Data Source Rules

Deployment pipelines offer two types of rules: parameter rules and data source rules. Parameter rules change the value of Power Query parameters. Data source rules change the data source connection directly (server and database) without requiring parameters. My recommendation for enterprise environments: always use parameter rules. They give you more control, work with custom M code patterns, and are visible in the Power Query Editor. Data source rules work silently and can be confusing to debug when a connection is not what you expect.

Automating Pipeline Deployments with REST API

For fully automated CI/CD, you can trigger pipeline deployments programmatically using the Power BI REST API. This integrates with Azure DevOps or GitHub Actions for automated deployment on merge to specific branches.

# PowerShell: Deploy from Development to Test stage
$pipelineId = "your-pipeline-guid"
$sourceStageOrder = 0  # Development
$targetStageOrder = 1  # Test

$body = @{
    sourceStageOrder = $sourceStageOrder
    options = @{
        allowOverwriteArtifact = $true
        allowCreateArtifact = $false
        allowSkipTilesWithMissingPrerequisites = $true
    }
    updateAppSettings = @{
        updateAppInTargetWorkspace = $true
    }
} | ConvertTo-Json -Depth 3

Invoke-PowerBIRestMethod `
    -Method POST `
    -Url "pipelines/$pipelineId/deployAll" `
    -Body $body

The parameter rules you configured in the pipeline settings are applied automatically during the API-triggered deployment. No additional code is needed to handle parameter switching.

6. Parameters and Incremental Refresh

Incremental refresh is one of the most impactful performance optimizations in Power BI, and it is entirely powered by two Power Query parameters. Getting this right is the difference between a 10-minute full refresh and a 30-second incremental one. I cover data modeling best practices in a separate guide, but the parameter configuration is critical to understand here.

The RangeStart and RangeEnd Naming Requirement

Power BI requires your incremental refresh parameters to be named exactly RangeStart and RangeEnd. The names are case-sensitive. If you name them rangestart, Range_Start, or anything else, the incremental refresh configuration dialog will not recognize them and will not let you enable incremental refresh on the table.

• Type must be Date/Time. Not Date. Not Text. Specifically type datetime in M.
• Current Value should be set to a reasonable date range for development. Example: RangeStart = January 1, 2024 and RangeEnd = today's date. Power BI overwrites these values during scheduled refresh in the Service.
• The filter must use both parameters with >= for RangeStart and < (strictly less than) for RangeEnd. This creates non-overlapping partitions.

Query Folding Verification

Incremental refresh is only efficient if the date filter folds to the data source. Here is how to verify query folding is working:

1. Open your query in Power Query Editor.
2. Find the filter step that uses RangeStart and RangeEnd (usually named “Filtered Rows”).
3. Right-click on that step in the Applied Steps pane.
4. If “View Native Query” is available and clickable, query folding is working. Click it to see the SQL that Power Query generates. It should include a WHERE clause with your date column.
5. If “View Native Query” is grayed out, query folding has broken. This means Power BI will load the entire table into memory before filtering, which defeats incremental refresh.

Partition Strategy

When you configure incremental refresh on a table, you define two windows:

• Archive period: How far back to keep historical data (e.g., 3 years). This data is loaded once and never refreshed again unless you do a full refresh.
• Incremental period: The rolling window of recent data to refresh on each cycle (e.g., last 30 days). Only partitions within this window are refreshed.

Power BI automatically creates partitions based on these windows. For a 3-year archive with 30-day incremental window, Power BI creates approximately 36 monthly partitions for the archive and daily partitions for the incremental window. During each scheduled refresh, only the daily partitions within the 30-day window are refreshed.

Incremental Refresh with XMLA Endpoint (Premium)

Organizations with Power BI Premium or Fabric capacity can use the XMLA endpoint for advanced partition management. This lets you refresh individual partitions on demand, create custom partition boundaries, and integrate with orchestration tools like Azure Data Factory. The XMLA approach gives you full control over the partition strategy that Power BI normally manages automatically, which is necessary for large-scale enterprise deployments with complex refresh requirements.

7. Security Considerations

Parameters are powerful, but they introduce security risks if misused. In compliance-heavy industries like healthcare and finance, parameter security is not optional — it is auditable. Here is what you need to know.

Never Store Credentials in Parameters

This seems obvious, but I see it regularly in enterprise environments. Do not create parameters for passwords, API keys, or connection strings that include credentials. Power Query parameters are stored in plain text in the .pbix file metadata. Anyone who downloads the .pbix file from the workspace can open the Advanced Editor and see every parameter value. Instead:

• Use the Power BI Service data source credentials to manage authentication. These are encrypted and stored separately from the semantic model.
• For API keys, configure the credentials in the gateway data source settings using “Key” authentication type.
• For SQL Server, use Windows Authentication through the gateway instead of SQL authentication with username/password parameters.
• For Azure services, use service principals or managed identities configured at the gateway or workspace level.

Gateway Data Sources and Parameter Binding

When your Power Query uses parameters for server names or database names, the Power BI Service needs to resolve the parameter values to determine which gateway data source to use. This can fail if:

• The resolved parameter value does not match any configured gateway data source.
• The parameter is used in a way that makes the data source “dynamic” (the Service cannot determine it at design time).
• Multiple gateways have data sources for the same server, creating ambiguity.

The fix is to pre-configure gateway data sources for every parameter value you plan to use. If your ServerName parameter can be sql-dev-01, sql-test-01, or sql-prod-01, all three must exist as data sources on the gateway.

Privacy Levels and Parameter Evaluation

Power Query's privacy levels (Private, Organizational, Public) interact with parameters in ways that can block queries entirely. When a parameter value from one privacy level is used to query a data source at a different privacy level, Power Query may refuse to send the query to prevent data leakage. This manifests as the cryptic error: “Formula.Firewall: Query references other queries or steps, so it may not directly access a data source.”

The most common scenario: a parameter value is combined with a Web.Contents URL (considered Public by default), but the data it retrieves is marked as Organizational. Power Query blocks this because it interprets the parameter as potentially leaking organizational data to a public source. The fix is to explicitly set matching privacy levels on all data sources that interact through parameters. In enterprise environments, setting all internal data sources to Organizational is typically the correct approach.

8. Common Mistakes to Avoid

After reviewing hundreds of enterprise Power BI implementations, these are the five most frequent parameter mistakes I encounter. Each one causes real production issues that are preventable with proper planning.

Mistake 1: Hardcoded Values Instead of Parameters

The most common mistake is not using parameters at all. Developers hardcode server names, database names, and file paths directly in M code. This works fine in development but creates a maintenance nightmare when the report needs to connect to a different environment. Every promotion requires manual editing, which introduces human error and makes automated deployments impossible.

Rule of thumb:If a value changes between environments or could change in the future, it should be a parameter. Server names, database names, file paths, API base URLs, schema names, tenant identifiers — all parameters.

Mistake 2: Not Enabling Query Folding

Using parameters for date filters (especially RangeStart/RangeEnd for incremental refresh) without ensuring query folding is the second most impactful mistake. When folding breaks, every refresh loads the entire table into memory, filters it locally, and then discards the filtered rows. For a 100 million row fact table, this means transferring all 100 million rows over the network on every refresh instead of just the new rows.

Common folding breakers: Adding a custom column before the filter step, using Table.Buffer() before the filter, applying a Table.TransformColumns() that the source cannot translate, or using M functions that have no SQL equivalent.

Mistake 3: Wrong Privacy Levels Blocking Parameter Evaluation

Mismatched privacy levels between a parameter and the data source it connects to will produce the “Formula.Firewall” error. This is especially common with web APIs where the base URL parameter is treated as one data source and the API endpoint is treated as another.

Fix: Go to File > Options > Privacy > “Always ignore Privacy Level settings.” This works for development but is not acceptable in production.For production, properly configure privacy levels on every data source in the gateway settings. Set internal APIs and databases to “Organizational” and ensure consistency across all sources that exchange data through parameters.

Mistake 4: Parameter Names with Spaces

Naming a parameter Server Name instead of ServerName causes issues in M code because you have to wrap the reference in #"Server Name" syntax every time you use it. This is error-prone, harder to read, and can cause subtle bugs if you forget the hash-quote wrapper.

Naming convention: Use PascalCase with no spaces: ServerName, DatabaseName, BaseApiUrl, TenantID, RangeStart, RangeEnd. This keeps M code clean and matches the convention used by Power BI's built-in parameters.

Mistake 5: Forgetting to Bind Parameters in Deployment Pipeline Rules

You create parameters, use them in all your queries, deploy to the Test workspace through a pipeline — and the report still connects to the development database. Why? Because you never configured parameter rules in the pipeline deployment settings. Parameters do not automatically change when deployed. You must explicitly tell the pipeline what value each parameter should have in each stage.

Checklist: After creating any new parameter, immediately go to your deployment pipeline, open Deployment Settings for the Test stage, add a parameter rule for the new parameter, set the Test value, then repeat for the Production stage. Build this into your development workflow so it never gets forgotten.

Related Guides and Services