Power BI Embedded is a Platform-as-a-Service (PaaS) solution on Microsoft Azure that offers a collection of interfaces to enable the integration of Power BI content into custom apps and websites.
You can use all the features, like cross-filtering, Row Level Security and Q & A. For creating reports, you can use regular Power BI Desktop. However, you are not limited to publishing your reports to Power BI service anymore. Additionally, Power BI Embedded enables you to integrate them into your own web and mobile apps. Not only for your organization, but also for third party users. They don’t even need a Power BI license, but instead can use your own authentication system which can be combined with Power BI Embedded’s powerful API.
Some people may recognize this as Power BI Workspace Collections. However, this Azure service was retired in June 2018 with Power BI Embedded as its successor. Microsoft even started to call Workspace Collections “Embedded Version 1”. Back then it had very limited functionality—e. g. only two data connectors, no bookmarks and no Q&A—and a dedicated API. Now Power BI embedded is closely linked with the well-known Power BI, offering the same features and using the same API.
What is the target audience of Power BI Embedded?
Microsoft directly mentions independent software vendors (ISVs) on their homepage, i.e. companies that are developing and offering their own software applications. They can use Power BI Embedded as a tool to distribute information made in Power BI to their customers through their own app.
In my opinion, this use case is a little too narrow. Many companies that do not focus on software products can also benefit from the capabilities of Power BI Embedded by presenting information they have to their customers or partners in a streamlined way and with a better look and feel. Imagine a bank which uses powerful visualizations in their mobile app to show you movements on your account combined with the interactive filtering offered by Power BI. Or a facility management company showing companies exactly the costs and services accrued per month including the ability to drill down from city to building to specific rooms.
Lastly, companies can use Power BI Embedded to distribute reports among their employees without providing a Power BI Pro license to every one of them. This is closely related to the next chapter which discusses Power BI Capacities in more detail. The suggested way by Microsoft is to purchase a Power BI Premium license for the company. However, if you simply want to embed Power BI reports into an internal information portal without using SharePoint or Power BI Service, a Power BI “A” SKU could be enough.
What does Power BI Embedded cost?
First of all, you need at least one Power BI Pro License (details discussed in the next chapter). Also, only Power BI Pro users are able to publish reports. Power BI Pro is € 8.40 or $ 9.99 per user per month as I am writing this article. For your first steps, this should be enough. You can get a limited amount of free embedding tokens whenever you register a new app in Azure AD.
If you are planning to go into productive state, you will need Power BI embedded capacity. This has to be assigned to the App Workspace your Power BI content is stored in.
What capacities are available?
Capacity is defined in SKUs (stock keeping units), the A-SKU, EM-SKU and P-SKU. All of these are divided into several node types with a different capacity for peak renders (page refresh, filtering, slicing/dicing) per hour.
The difference can be found here, key takeaways are:
A SKU: The “Azure” SKU. Can be purchased via the Azure Portal and is billed hourly. It is the cheapest if you just want to test Power BI Embedded. Since it doesn’t come with any commitment, you can pause or quit any time and also scale up and down. However, it only allows integration of content into your own application. Pricing starts at $ 1.0081 per hour, but can increase up to $32.26 per hour if the biggest capacity is needed.
EM SKU: EM SKU is purchased through Microsoft Office 365 Administration Portal. It costs a monthly fixed fee and can only be purchased for a whole year in advance. It gives you the ability to embed content into your own application. Additionally, Power BI FREE users can access embedded content in Share Point Online and Microsoft Teams. Pricing starts about $ 650 per month, which allows for up to 300 renders per hour.
P SKU: P SKU can also be purchased in the Office 365 Administration Portal. It enables you, additionally to the EM SKU’s capabilities, to give Power BI FREE users access to Power BI Service. However, you have to commit for a full year and it sets you back at least $ 5000 per month. It allows for up to 2400 renders per hour and can be scaled even further up.
So which one is the right one for you?
First of all, you need to decide whether you want to commit for a full year and if you need any of the Microsoft services like Power BI Service or Sharepoint. If not, or you just want to try to embed a report into your app, it is best to start with the A SKU. Microsoft also released a whitepaper to help you determine which one is the best here.
However, using the EM SKU could be cheaper than the A SKU in the long run, if you plan 24/7 availability. P SKU is only needed, if you really expect many users to access your report or you don’t want to miss out on the Power BI Service.
It is simply not possible to give clear advice here, since so many factors have to be considered. It’s totally dependent on your context.
How do you create an application with an embedded Power BI report?
Microsoft uses the two terms ‚App owns data‘ and ‚User owns data‘ when it comes to using Power BI Embedded. The main difference is that ‚User owns data‘ means every consumer has to have an Power BI licence. However, this is usually not applicable when you want to supply Power BI reports to your customers. So I will focus on the ‚App owns data‘ use case.
Setting up the Power BI and Azure Environment
Let’s assume you have acquired the capacity to embed your Power BI content. What should you do now to embed your report? The obvious first step: Create a report you would like to embed. You can use Power BI Desktop for this and use any feature there you want such as Row Level Security, custom visuals or bookmarks.
You then have to set up an environment to embed this report into your customer app. Fortunately, you can use a wizard for this. This will guide you through every necessary step to prepare Power BI to be embedded.
After signing in to your Power BI Pro Account, you can select permissions for the API. As soon as you click register, these will be used to register the app in Microsoft Azure AD. The Azure Portal is also the place where you can see and change the settings for it. Just search in Azure Active Directory for App registrations and you should find it.
Registered apps in Azure AD, including our newly created PBIE Customer Example. The next two steps help you to set up your Power BI service by creating an App Workspace and importing your report into it. If you are already familiar with Power BI Service and have uploaded your report there, you can also skip them. Please note, that you have to publish your App Workspace as a Power BI App manually.
The fifth and final step to set up your environment is to grant the app permissions. Like everything else, you could do this manually (in the Azure Portal), but here it is just a click on a button.
That’s it. You are done and free to embed your Power BI reports into your own app. You can even download a sample web app, prefilled with your parameters, to test everything.
Setting up your Application
Let’s just assume you already have a nice application for your customers or colleagues to use. Or you are gonna build it from scratch, but already know how to do it. You just want to include content you created in Power BI.
You probably have some kind of user management to control access to your information. Usually, the user who wants to access the page with the embedded report signs in via the application front end. In the application backend you now have to trigger a token generation, using the ‚master user‘ which owns the Power BI App Workspace. This token is given to the report consumer’s frontend and enables it to access Power BI’s API. This way, the reports which are available for the master user can also be embedded into your application and the user can see everything the master user can see.
You can also use this method to use the concept of Row Level Security (RLS). This means, you create one report for every user to see, but these users can only see certain rows of this report based on his or her role. For example, a team lead can only see data for his or her team. The configuration is usually done in Power BI Desktop or an underlying Tabular model, whereas the roles are assigned in Power BI Service. Usually Power BI retrieves information about roles from the AD user. Since not every consumer of your application has one of these, you must pass this information some other way. The way to do so is to extend the aforementioned authentication token. It now needs, besides information about your master user, a JSON array with the username, roles, and applicable datasets of the consumer. A detailed explanation can be found here.
Embedding your Power BI content
Show reports and dashboards: Obviously, you can load and show dashboards and reports inside your own application. These will use the same functions as the regular content in Power BI Service.
Set Filters and Slicers: If you embedded a report, you can also manipulate the filters from the outside of the report, but inside your application. This way, you can even achieve things which are not possible in Power BI Service, like filters across several reports.
Manipulate Datasets: You can enable the application user to get information about certain datasets in your application. You can also enable to add rows to these datasets.
You can find a great interactive demo which also lets you see the used commands.
If you like the report creation in Power BI and want to give your customers access to it, Power BI Embedded is a great way to do so. You can use your well known software with the usual analytic capabilities.
Another point you should consider are the costs. If 24/7 availability is needed, using the „A“ SKU can get quite expensive. It is also kind of hard to estimate the right capacity, since the peak renders per hour are not easy to predict. You have to know the number of users, but also the interactivity they will use, since every cross filter, filter or drilldown triggers a new render.