You’re offline. This is a read only version of the page.
10
We have a model driven Power App that we deploy to multiple production environments. Separately, we have a Power BI app that contains reports and datasets for reporting on the model driven app. In the model driven app, we use Power BI dashboards with environment variables to point at the Power BI App so users can view the Power BI reports inside the model driven app. The model driven app and Power BI app are maintained in a dev environment, moved to test and eventually multiple production environments. We have fully automated the model driven app deployment lifecycle using Azure DevOps. Unfortunately, the Power BI app lifecycle is not well supported. It is a manual process to create the app, promote it, install it in test, update the connection to Dataverse, and eventually deploy it to production.
The approach works, but it is challenging to maintain. With each update, the Power BI app must be recreated and redeployed manually, by a human being. The first time it's deployed, the human also needs to add the workspace and report ids to environment variables so the reports will render in the model driven app and add security to the Power BI workspace to allow Power Apps users to view the reports. This is not a scalable solution to deploy across multiple instances.
One year ago, Microsoft released the preview version of Power BI reports and datasets in solution files, presumably to address the challenges above. When a Power BI report and dataset are included in a Power Apps solution, Power BI creates a dedicated workspace for the Power Apps environment. When that solution is deployed to a target environment, a new Power BI workspace is automatically created for the environment containing the reports, datasets and permissions. It works great, except it only works when a human manually deploys the solution. And we deploy our solutions using Azure DevOps.
We utilize Azure DevOps repositories and pipelines to store, build and deploy our Power Apps solution files. The pipelines use a service principal to run solution installs. If we use this infrastructure to deploy a solution containing Power BI reports and datasets, we get message "This solution contains Power BI components, so it couldn't be imported. To complete your import, sign in to Power BI".
To install a solution that contains Power BI reports and datasets, the service wants an authenticated user with a Power BI license. We tried to follow these steps, but it didn't work either. It appears that service principal deployment is not supported for solutions that contain Power BI reports and datasets.
It's been 1 year since the preview was released and there is still no announced date for general availability. Maybe Microsoft will fix this in the general release. For now, this limitation severely restricts the benefits since a human with a Power BI license needs to install the solution, which is what we already have to do with Power BI apps. This could be a great feature but if you use pipelines and service principals, don't waste your time with it.
Thank you for confirming my suspicions @james_tekstack
Agreed that this should be addressed as it kills the ALM capabilities for solution-aware PBI components for enterprises using ADO
Share
Report
All responses (
Answers (
