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 Thanks for your feedback. I am agree with you, this is a very interesting discussion. So I have 2 question.
1- you say you currently use Qlik, but you are going to move to Power BI. I used QlikView & QlikSense and both are powerfull tools. So why are the main reasons for you desicion?
2- according to your aproach, you develop in Power BI Desktop a model based on views from Azure SQL using import Mode, you design your model and then you upload this to the service. So because Azure SQL is in the cloud, you don't need to use a gateway. That's what I understood... I am right?
Any comment would be helpful. Thanks in advance
alexanderg Sorry for this late reply.
1. It's not my decision, it's from top management but the main reason is mostly related to money, Power BI is cheaper and have better and modern UI. But we did not get rid of Qlik totally we try to use Qlik and Power BI in parallel since all our current clients are using Qlik, we do offer power BI for new client and even for current clients who want to move from Qlik to Power BI (some client request to integrate Power BI instead of using Qlik).
2. Yes, you are asolutely right :)
alexanderg and Anonymous,
The Power BI Embedded is really potential, we are investigate it in order to change from Power BI Service to Embedded, the benefit is great:
1. No Office 365, no Azure Sync, the security on report level, not on user level, so the approach to integrate Power BI to application is simpler.
2. Cost saving.
3. Connection String can be changed programmatically.
One limitation I know so far:
1. No support scheduling on "Import Data" mode.