Forum Discussion
Approach for build a scaled solution
This is just one approach, but I like it for security/backup/ease of use. It leverages AD, the Desktop and the Service.
1) Security is managed via AD groups to simplify user management. You have control of which end users can read the model, which users can publish reports via that datasource (Enterprise Gateway), which users have access to the Power BI Groups. This also allows for row level security on the model level).
2) I use the desktop to build/update reports using my SSAS connection. This gives me backups/version control because I have the file which I can re-deploy anywhere, and I can store it in any number of locations including those like Sharepoint where I can see modified dates, etc.
3) I use Power BI Groups as the only place to pull company level reports into. This gives me the ability to have a group of people manage reports and own them, so everything isn't in one persons workspace.
4) For most end users, a shared dashboard is going to be easier to understand, so that is typically the best way I've found to intially start sharing reports. Although Content Packs are powerful, and I think are a great "Step 2" for implementing certain solutions, but only after I'm sure the owners and end users know how to use them.
This is a really high level broad strokes bullet point list, but it's typically my recommendation path for larger scalable solutions. At this point in time building business processes has to take the place of admin controls or features since those are not in the tool by default. I'm hoping more of the capabilities are added over time.
cuongle I'm going to take a really broad stroke at this because there are many different elements to all your questions. But before I dive in, is there a reason you are not using a tabular model? This would basically provide a better solution than what you outline in 1-3 and cover the row level security needs I think you reference in #4.
Azure AD is required regardless, but there are many areas of that I am not familiar with in syncing requirements and things you can/can't do with your on premises AD.
Anonymous Thanks for your quick response.
Well, the reason why we did not go with the route SSAS is because the system is built over 5 years ago and we do manage Facts/Dimensions over star schema by ourselves. it is really dynamic to align with our business and even allows end users doing "Tagging" (change Dimension Foreign Keys on Fact table) which we think SSAS is not relevant for us.
So that's why we go ahead with Database Views.
cuongle gotcha. Since you didn't correct me, I'm assuming your question revolves around row level security. The only ways I am aware that you can apply row level security are in tabular models (which you aren't using) and sometime within a month, there will be some RLS functionality deployed within Power BI (As announced at Data Insights). I don't know if it will work in all instances (Direct Query) or just on imported data. Outside that, sql 2016 will allow RLS on a database if I'm not mistaken.
If this doesn't answer what you are looking for, let me know.
cuongle The Service update today just released the Row Level Security feature. Check it out to see if it works for you.
https://powerbi.microsoft.com/en-us/blog/power-bi-service-march-update-part-two/#usage
Anonymous Thanks for you reponse, I don't have any specific question :), I just want give our initial approach for PowerBI and would like to hear the feedback if needed or there is something not corrective much with this approach.
Thank you for the link, highly appreciated. This is what we expected, with this feature we just need one dashboard for each client.
Cheers