Power BI is turning 10, and we’re marking the occasion with a special community challenge. Use your creativity to tell a story, uncover trends, or highlight something unexpected.
Get startedJoin us for an expert-led overview of the tools and concepts you'll need to become a Certified Power BI Data Analyst and pass exam PL-300. Register now.
I got a dataflow that we have published in a workspace that is part of a deployment pipeline (DEV-QA-PROD).
I have defined parameters to allow changing the workspace Id and dataflow Id in Power BI Service and in the deployment pipeline rules.
The issue I have is that for a specific dataset, it does not follow the parameter's value, but strictly points to PROD.
So for example, I have this parameter for the workspace Id:
/// DEV: workspace_dev_id
/// QA: workspace_qa_id
/// PRD: workspace_prod_id
expression WS_WORKSPACE_NAME = "workspace-dev-id" meta [IsParameterQuery=true, List={"workspace-dev-id", "workspace-qa-id", "workspace-prod-id"}, DefaultValue=..., Type="Text", IsParameterQueryRequired=true]
And this parameter for the dataflow Id:
/// DEV: dataflow_dev_id
/// QA: dataflow_qa_id
/// PRD: dataflow_prod_id
expression DF_DATAFLOW_NAME = "dataflow-dev-id" meta [IsParameterQuery=true, List={"dataflow-dev-id", "dataflow-qa-id", "dataflow-prod-id"}, DefaultValue=..., Type="Text", IsParameterQueryRequired=true]
Now, when I want a query to use those parameters I would create the request using the "Get data" wizard and the replace the `workspaceid` and `dataflowid` values by the parameter names :
let
Source = PowerPlatform.Dataflows([]),
Workspaces = Source{[Id="Workspaces"]}[Data],
workspaceId = Workspaces{[workspaceId=WS_WORKSPACE_NAME]}[Data],
dataflowId = workspaceId{[dataflowId=DF_DATAFLOW_NAME]}[Data],
entity = dataflowId{[entity="Entity Name"]}[Data]
in
entity
I just realized that whatever value I choose in the list for any of the parameters it points to PROD values.
Even after it is deployed in Power BI Service it stays that way. I can change the dataset's parameter values but it keeps reading PROD.
I even tried with new parameters but it keeps going to PROD values.
Any ideas what I should look for?
*edit* : Th ebiggest issue is that even if the workspace parameter is set to connect to DEV, and the dataflow id is one from QA, it still returns data from DEV.
Saving the file as PBIX and save it again as PBIP corrected the issue but it also changed the internal IDs of the report and the semantic model in files named ".platform".
Fortunately, we use git to do version control and I was able to change it back to the previous values :
So if anybody is experiencing this issue I would add to make sure they backup the internal values before they convert it to PBIX. And also to change them back to the riginal values if they are using git integration because the "source control" feature in Power BI Service is not able to match the objects by their names, only by internal IDs.
It will show the objects twice and you will not be able to go any further until you change the internal IDs.
Seems Like I was a bit too quick to say that converting it to pbix did the trick.
It did not.
I'm still having issues where even by recreating the query using the wizard, it still does not point to the right workspace.
Hi @FireFighter1017,
Power BI Desktop may not always apply parameter overrides for dataflow queries correctly, particularly when queries are created using the wizard. The wizard often embeds static workspace or environment values in the M code, which can prevent parameters from functioning as intended.
To address this, consider manually editing the M code in Power Query to ensure the workspace reference is sourced from your parameter.
Also, clearing and re-establishing permissions through File -- Options -- Data source settings can help, as cached credentials might be maintaining a link to the previous workspace.
As a troubleshooting step, you can create a test table referencing your parameter to confirm it resolves properly within the Desktop file.
If nothing works, we suggest submitting your detailed feedback and ideas through Microsoft's official feedback channels, such as Microsoft Fabric Ideas. Feedback submitted through these channels is frequently reviewed by the product teams and can contribute to meaningful improvements.
Hi @v-sshirivolu ,
So here are my test results (so far):
1. Clear Data Source Settings in Desktop:
2. Inspect PBIP Files in Git:
Hi, I'm having the issue in Power BI Desktop. Power BI Service is setup correctly for parameters override.
Hi @FireFighter1017 ,
Thanks for reaching out to the Microsoft fabric community forum.
This issue occurs because Power BI deployment pipelines automatically override dataset parameters according to the rules set in the environment configuration.
Therefore, even if you update the parameter in Power BI Desktop or manually republish with DEV/QA values,
the deployment pipeline will still replace the parameter values with those configured for the current environment, which in your case seems to be PROD.
Review and Update Deployment Pipeline Parameter Rules
In Power BI Service, go to the deployment pipeline containing your dataset.
Navigate to the relevant environment (such as QA or DEV).
In Deployment Settings, check the Parameter rules.
You may find parameters like WS_WORKSPACE_NAME and DF_DATAFLOW_NAME set to PROD values.
Update them to the correct DEV/QA values for that environment and save your changes.
Disable Parameter Override (Optional)
If you want to prevent deployment pipelines from overriding your parameters, uncheck "Override during deployment" for each parameter in Deployment Settings.
However, it is generally recommended to configure parameters correctly for each environment rather than disabling overrides.
Additional Validation
To test in Power BI Desktop, set the parameter to a QA/DEV value and verify that the query editor preview uses the correct data source. After publishing to a specific workspace, check the parameter values in the dataset settings. If using a pipeline, ensure it is not overriding these values during deployment.
Following these steps will help make sure your workspace and dataflow IDs are set correctly for each environment and that parameters work as intended.
If the response has addressed your query, please Accept it as a solution and give a 'Kudos' so other members can easily find it
Best Regards,
Sreeteja.
Community Support Team
Also, DEV can't have deployment rules. Even though I change the parameter values in the Datset settings in Power BI Service for DEV, it still reads data from PROD. I also tested if the workspace parameter has QA's GUI and the dataflow has DEV GUI, it still returns data from PROD.
As I mentionned, the biggest issue is that we did your "Extra validation" and we have this behavior in Power BI Desktop.
Because we are using Git Integration with Github, we save our reports as PBIP. So when I open the report in Desktop mode, I do it from the local repository.
The report in Power BI Service DEV is updated through Git integration from Github.
Hi @FireFighter1017 ,
Thanks for reaching out to the Microsoft fabric community forum.
Power BI Desktop may cache previous connection info from the PowerPlatform.Dataflows() connector, so even if you update parameters, it might still use old PROD details from connections.json. This can make parameter changes seem ineffective.
Try These steps:
1. Clear Data Source Settings in Desktop:
Go to File - Options and Settings - Data Source Settings.
Clear permissions for Power Platform and remove cached connections.
2. Inspect PBIP Files in Git:
Check parameters.json – confirm the right values are set.
Check connections.json – this may have hardcoded workspace/dataflow IDs that override parameters.
3. Regenerate PBIP Cleanly:
Try opening a clean .pbix (not from PBIP), and test parameters for DEV.
Once confirmed working, export it as PBIP again.
Compare the new connections.json with your repo version.
4. Consider Switching to OData.Feed():
Instead of using PowerPlatform.Dataflows(), try:
let
url = "https://api.powerbi.com/powerbi/globaldataflows/v1.0/myorg/groups/" & WS_WORKSPACE_NAME & "/dataflows/" & DF_DATAFLOW_NAME,
data = OData.Feed(url)
in
data
This gives full control over the connection URI and respects parameters reliably.
The issue is most likely caused by how PowerPlatform.Dataflows() behaves in PBIP projects it's not always reactive to parameter changes due to caching and metadata binding. Using OData.Feed() or cleaning out connections.json may help regain control.
If the response has addressed your query, please Accept it as a solution and give a 'Kudos' so other members can easily find it
Best Regards,
Sreeteja.
Community Support Team
Hi @FireFighter1017 ,
Just wanted to check if you had the opportunity to review the suggestion provided?
If the response has addressed your query, please Accept it as a solution and give a 'Kudos' so other members can easily find it.
Hello @v-sshirivolu ,
I'm currently reviewing your suggestions.
I'll let you know once I've gone through.
Hi @FireFighter1017 ,
Thank you for the update. Please try the suggested steps and let us know the outcome, we're looking forward to your response.
Hi @FireFighter1017 ,
Just wanted to check if you had the opportunity to review the suggestion provided ?
If you have any questions or run into any problems, please feel free to reach out.
Hi @FireFighter1017
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions. If my response has addressed your query, please Accept it as a solution so that other community members can find it easily.
hi @v-sshirivolu ,
I have good knowledge of how deployment rules can change dataset parameters in Power Bi Service.
My Issue is that even in Power BI Desktop, if using a workspace parameter set to workspace-prod-id and a dataflow parameter set to dataflow-dev-id it still works and will return whatever functionnal connection I had before. (ex.: workspace-prod-id , dataflow-prod-id )
This is your chance to engage directly with the engineering team behind Fabric and Power BI. Share your experiences and shape the future.
Check out the June 2025 Power BI update to learn about new features.
User | Count |
---|---|
58 | |
56 | |
56 | |
38 | |
29 |
User | Count |
---|---|
75 | |
62 | |
45 | |
40 | |
39 |