Forum Discussion
thoughts on design principles
I'm currently develeoping a report using PBI desktop on my own machine and publishing it to the Service.
My report has connections to 3 existing semantic models in order to create a Company wide report.
When I publish this to the service, I have noticed in the Manage connections, it has created 3 Analysis Sevices connerctions.
My question is what happens if I were to leave the org (as my account will be disabled) - will this conenction still work?
I'm unable to add colleagues in the users and this connection has been authenticated using my windows logon, but should be a service account instead.
Then the list of Analysis Services conenctions will grow, therefore become a bit messy to maintain.
If I wasn't to connect to semantic models, my alternative approach would be to import the same data from the Data Warehouse, but this means repeating steps to create Measures, but the PBIX would be cleaner and reduced size.
Any thoughts, tips and suggestions much appreciated.
Hi _bs_
The current architecture using Composite Models (DirectQuery over Power BI Datasets) is the correct approach and aligns with the industry standard for "Golden Datasets." The appearance of "Analysis Services" connections is technically accurate because every Power BI Dataset is hosted on an internal Azure Analysis Services instance; this is not "messy" but rather how the backend exposes the connection string.
Regarding the concern about a user leaving the organization, this is an administrative task rather than an architectural flaw. If the original owner's account is disabled, another workspace admin can simply use the "Take Over" feature in the dataset settings to transfer ownership and update credentials. Ideally, for production environments, the connection should be authenticated via a Service Principal to decouple the report's lifecycle from individual employees entirely.
Switching to the proposed alternative of importing data directly from the Data Warehouse would be a strategic error. It creates "Data Silos," forces the redundant recreation of measures across multiple files (violating the DRY principle), and increases maintenance overhead significantly. If a business definition changes, you would have to update every individual file rather than just the upstream semantic model. Sticking to the shared semantic model ensures a "Single Version of the Truth" and efficient capacity usage.
If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly
4 Replies
Hi _bs_
The current architecture using Composite Models (DirectQuery over Power BI Datasets) is the correct approach and aligns with the industry standard for "Golden Datasets." The appearance of "Analysis Services" connections is technically accurate because every Power BI Dataset is hosted on an internal Azure Analysis Services instance; this is not "messy" but rather how the backend exposes the connection string.
Regarding the concern about a user leaving the organization, this is an administrative task rather than an architectural flaw. If the original owner's account is disabled, another workspace admin can simply use the "Take Over" feature in the dataset settings to transfer ownership and update credentials. Ideally, for production environments, the connection should be authenticated via a Service Principal to decouple the report's lifecycle from individual employees entirely.
Switching to the proposed alternative of importing data directly from the Data Warehouse would be a strategic error. It creates "Data Silos," forces the redundant recreation of measures across multiple files (violating the DRY principle), and increases maintenance overhead significantly. If a business definition changes, you would have to update every individual file rather than just the upstream semantic model. Sticking to the shared semantic model ensures a "Single Version of the Truth" and efficient capacity usage.
If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly
Hi _bs_ ,
Has you refer the best practice is to have this connection made using a service account and not your personal account and then share it with other users that can then connect to it.
If you leave the company then the connection will not work however a colleague can take over the semantic model and redo the connections and everything will continue to work because the connection to the specific datasets will be redirected.
I advise that you try and check with your admin an option to get a service principal to take over the connection and then shared it with you.
If the report is published in Power BI Service, it will continue to work only if the data source/gateway credentials are set with a service account. Since it’s currently authenticated with your Windows login, refresh and connections will likely fail once your account is disabled. Best practice is to switch to a service account and shared ownership. External or Desktop live connections using your identity would break.
Regards!Hi _bs_ ,
Thanks for reaching out to the Microsoft fabric community forum.
I would also take a moment to thank Ritaf1983 and MFelix , for actively participating in the community forum and for the solutions you’ve been sharing in the community forum. Your contributions make a real difference.
I hope the above details help you fix the issue. If you still have any questions or need more help, feel free to reach out. We’re always here to support you .
Best Regards,
Community Support Team
