A couple caveats and solutions for enterprising PowerBI
Enterprise report delivery with powerBI
One of the lessons most people will learn while enterprising cloud solutions is that you will trade off the cost, security, and convenience of a cloud application for the lack of control around it. Microsoft tends to change powerBI at their own pace.. This can lead to the presentation of the tool appearing differently to users. What I’ve done with clients is to abstract those changes from the user, such that the behaviours within the organization can be more easily nurtured. We direct all traffic from a sharepoint landing page to any type of asset. Those assets can be powerBI reports, excel online files, or SSIS reports.
In powerBI, the way to manage this is to add the report to the dashboard, and share the dashboard with the user. Once the user has been granted access to the dashboard, they will automatically have access to the report. The URL of the report will typically look like https://app.powerbi.com/groups/me/reports/[reportUID]/ReportSection, where the reportUID is a random identifier provided by the cloud when the PBIX is published. I prefer to link the landing page to the report, and not the dashboard. The reason for this is that the dashboard may have some of the functionality of the report, but not all. Users who are unfamiliar with the system have a hard time understanding the difference, so presenting them with the report just saves the confusion all together. This approach has worked very well when report and dataset modelling are contained.
I have another environment in which users want to build on top of the data model, and create their own reports. Originally, we thought we might be able to use a content pack, but all of the objects presented to the power users would be read only. If the user wanted to build something off an existing data model, they would have to copy it and it would become stale. In order to make this work, we created another group in powerBI and granted users access to it so they can build on those data sets. Since the datasets are being refreshed in that group, the powerusers will always have access to the most current dataset. BRILLIANT! Mellissa Coates outlines the different approaches here.
We share reports within the group the same way as we would from a personal gateway. A dashboard is created in the group, the dashboard is shared with the user, and the link to the report is put on the landing page. Now to the caveat; when you grab the url for the report in the group, you’ll notice the URL will look more like: https://app.powerbi.com/groups/[groupUID]/reports/[reportUID]/ReportSection, where the groupUID refers to the group we are sharing. If you try and share that report to someone who is not in the group, even thought you just granted them access to the dashboard, it will not work. Be sure to replace the groupUID with “me” to make the link work. You can also share the dashboard with yourself, and access it from within your own workspace. Drilling down to the report will yield you the correct url.
Enterprise gateway doesn’t support composite data sets
A composite data set is a dataset that has both on premises and cloud data sources. If you were to build a data source that connects to a local mssql instance, and a file on sharepoint online, you are currently only able to use the personal gateway. My “test with” data set has an oracle source
thankfully this feature is now under development, and is likely to be released soon. For the moment, the only solution is to leave the personal gateway running on a machine, and disconnecting your session. That will create problems You can see the idea here.