Forum Discussion
Open Group Workspace instead of My Workspace by default
cmn Let's clear the air on a couple things. I agree on the "My Workspace", it is not the way to share on a corporate level.
Also agree on Content Packs - it's not an easily understandable concept for large numbers of users to grasp. (May be relevant for smaller groups, but with alot of explanation)
What I meant by "Report Owner Group" is the PBI Group that is created for the people you will hand off all the report management and sharing.
Your use case is very similiar to several I've been a part of thus far (I'm also a consultant).
Here is how I see your scenerio, and some ideas based on my implementations.
1) Access to individual or AD group is supported in all sharing scenerio's - not an issue
2) Read only - Shared dashboards (simple, clean, easy to explain to end users). Everyone has their own workspace, here are your company dashboards, and how you use them.
3) Hide Dataset, you have to use Dashboard sharing, Content packs expose all parts of a dashboard. (reports/datasets)
4) Multiple admins - Create one PBI Group to manage reports and sharing to end users. This could be multiple groups based on different departments, but this depends on size of company or number of reporting groups, etc. But suffice to say, I think there should be only a limited number of sources for reports to be shared from, it's easier to manage, and also easier to track down where issues come from.
5) There is the all or nothing approach to permissions in PBI Groups right now, so that's hard to manage. Currently the only way to manage some aspects of a large deployment is in the business process, and not the tool yet. In my implementations, I recommend that all reports be created and managed in PBIX files - this assumes that the backend allows for Direct Query or live connection. For large implementations, I hope this is the case (otherwise there may be a size issue with the file 250mb).
Using the PBIX files, you can create a process for a "hacked" way of version control. Either in a file share location like Sharepoint, TFS, or something where you can have a backup of your reports, and know who modified a file. That way, if anything happens to reports in the service, there is minimal downtime to re-deploy. This excludes Dashboards as those only exist in the Service, but those are easy to re-create.
I look forward to more of the governance/admin capabilities as well, but in the mean time I've found that there are ways in which I can replicate what I need in the business process to get me to a comfortable point.
This isn't to say that there is only one approach, but I find that in order to get early adoption for any new BI project, the easier it is to use for end users, the better. Creating shared PBI Groups to share dashboards or content to another PBI Group for end users seems unecessarily complicated to me and harder to explain
- Got kinda long winded there, would love to hear feedback/what your approach has been.
Hi Eno,
Thanks for this post - very useful.
There is a small problem with that approach and backing up the reports in .pbix files.
You can't deploy a PBIX file to a group at the moment. How are you getting around this issue when you have a group of Power BI users making changes to the reports?