Forum Discussion
Dataflow using Gateway for SQL turns to a Personal Cloud Connect on publish
Hi bdnypa,
Thanks for the clarification, and it’s good to hear that using the semantic model works as expected.
Your expectation about the gateway helping with easier administration is understandable. However, the gateway mainly provides secure connectivity between Power BI and the data source, and it does not automatically abstract or handle server name changes unless the gateway data source configuration and semantic model are updated accordingly.To minimize maintenance when server changes occur, the recommended approach is to use a centralized semantic model and connect reports to it instead of directly connecting to the server. This way, if the server changes, you only need to update the connection in the semantic model or gateway data source, and all dependent reports will continue to work without requiring individual updates.
Thank you again for using the Microsoft Fabric Community Forum.
I'm not doubting it - it just presents me with some questions. By Oath, I am assuming it means the users Id and password, which I think would be an admistrative issue since every user who publishes would need access to the data.
What we are trying to do is create datasets that can automatically refresh from existing data processes in SQL and publish them in PBI. The dataflow seemed a natural fit, until our first user published and the data does not refresh.
What is the best way to provide users with datasets that they do not control, do not require their own personal authorization and connect to the SQL data that can automatically be refreshed? After research, it sounded like a dataflow was the answer until this suprising twist.
The workaround is as you suggested. I created the dataset on my desktop as a semantic model and published the SM. That keeps the gateway connection and does not create a second semantic model when they use it for their reports. I don't find this a straightforward and clean solution as I should just be able to make the dataflow and have that shared. For this, we need PBI desktop and update the appropriate workspaces. It is interesting to me that one changes to the cloud connection while the other retains its connection when they are both really doing the same thing.
Community SupportHi bdnypa,
Thank you for the detailed follow-up.
When a dataset consumes a Dataflow, it becomes its own refresh object in the Service and does not inherit the gateway credentials used by the Dataflow. That is why OAuth is required at the dataset level and why it appears as a cloud connection. This behaviour is by design, as Dataflows handle transformation, while credential storage and refresh governance are enforced at the semantic model layer.
If your goal is centralized control (automatic SQL refresh, no per-user authorization, and users not owning datasets), the recommended approach is to create a single centrally managed semantic model connected directly to SQL via the Enterprise Gateway, configure scheduled refresh once under a BI/service account, and allow users to build thin reports using that shared dataset.
This ensures refresh runs centrally, avoids personal credentials, prevents duplicate semantic models, and provides a clean, governed enterprise setup.
Thanks again for using the Microsoft Fabric Community Forum.
- v-kpoloju-msft
Hi bdnypa,
Just wanted to follow up. If the shared guidance worked for you, that’s wonderful hopefully it also helps others looking for similar answers. If there’s anything else you'd like to explore or clarify, don’t hesitate to reach out.Thank you.