I’m a heavy user and fan of Power BI. It’s a great tool for building reports from multiple data sources and easily sharing them with others. I use it for a variety of internal needs – pulling data from databases, Excel and CSV files, and our telemetry logs into reports shared with others in the organization.
This past week was my first opportunity to explore Power BI Embedded. The capability enables you to embed Power BI analytics into an application. We use this extensively in Dynamics 365 Finance and Operations, but my use case was a little different. My scenario is one where the “app owns the data”.
The tutorial, https://docs.microsoft.com/en-us/power-bi/developer/embed-sample-for-customers#set-up-your-embedded-analytics-development-environment, is very good and I was able to get the sample up and running without much difficulty. One hurdle in the setup had to do with having access to an AAD tenant admin. Let me explain that further.
The diagram in https://docs.microsoft.com/en-us/power-bi/developer/embedding#embedding-for-your-customers shows the authentication flow. The tutorial above walks you through this setup, where one of the prerequisites is having an AAD tenant for which you are an administrator.
Not fulling appreciating this requirement, I first attempted to set up the tutorial on an internal Azure subscription that is connected with the MSFT corporate active directory. I quickly realized that I was not, and never would be, an administrator for that tenant!
Then I thought I could use my personal Azure subscription, but Power BI quickly cut me off when I tried to create a workspace. You need to have a work or school account associated with the subscription.
So I ended up creating my own tenant – dfroslie.onmicrosoft.com. Once I did this, the tutorial steps to hard code the proper IDs into the app were quite straightforward.
The next thing that I wanted to explore was Row Level Security (RLS) in Power BI. In my use case (note for Dynamics readers, this is a capability targeted for LCS), I needed the data filtered at run-time based on the user that was accessing the report. RLS is the tool that enables this scenario.
Fortunately, there is a good walkthrough for this (https://docs.microsoft.com/en-us/power-bi/service-admin-rls) and the “App owns data” sample app from the tutorial above supports the scenario. There were two related decisions that I needed to make:
-
-
- How I would use the user information provided to the report to do the filtering.
- How I would set up my data model to properly filter the report.
-
Ultimately, I decided that the domain name (user@domain.com) was the information that would best filter the data. To make use of this in the report, I needed a table that mapped domains to the report information. To mock this up, I created a simple table with Domain in one column (“Org”) and the relevant ID in the other column. The ID is related to other tables in the report and properly filters the entire report based on the domain.
Then I created a security role in Power BI with the following DAX expression. UserPrincipalName is the API in Power BI that returns the user that logged in using the form ‘user@domain.com’. The DAX expression extracts ‘domain.com’ from that string.
This leads to the following in the sample app. The left hand side matches a domain that is in the table that mapped domains to report information. The relevant data is displayed in the report. The right hand side had no match, and therefore no data is displayed.
Now that I have a better understanding of Power BI Embedded, I’m looking forward to taking the next step of building app capability with it!
Picture details: 12/16/2018, Ice fishing on Grass Lake, Maplewood State Park, iPhone 7, f/1.8, 1/760 s, ISO-20