Embedding Analytics in Power BI: Reduce Costs and Customize the Customer Experience

Hello everyone!

If you work with Power BI and have ever needed to share reports with dozens or hundreds of users, especially those outside your organization, you have likely felt the burden of individual licenses. Power BI Pro, Premium Per User (PPU)... the bill adds up quickly. But there is an official Microsoft alternative, completely legal and much more cost-effective: Embedding Analytics.

In this article, I will cover the entire subject from scratch: what Embedding Analytics is, how it works, which licensing models are available, the dedicated capacities involved, the technical concepts of Fabric's smoothing, bursting, and throttling, the risks of solutions that stray from the official model, frequently asked questions, and how you can implement all of this securely and efficiently in your company.

The Challenge of Distributing Power BI Reports

In the standard Power BI model, anyone who wants to view a report published on the service (app.powerbi.com) needs a Microsoft account and, in the vast majority of scenarios, a Power BI Pro or Premium Per User (PPU) license. This creates a real barrier on three fronts:

• High cost: Every user who needs to access reports has a monthly license cost. For small internal teams, that's fine. But when you need to share with customers, partners, resellers, or franchisees, the cost scales linearly, and quickly.
• Generic experience: The Power BI portal was created for the company's BI team, not for the end customer. The visual identity is Microsoft's, the navigation is technical, and often the user does not have the necessary context to navigate on their own.
• External access limitations: Users outside your organization need to be added as guests in Azure AD, which brings management complexity and, often, resistance from the IT department.

It is precisely to solve these problems that Microsoft created the Power BI Embedded Analytics feature, better known as Embedding Analytics.

What is Embedding Analytics in Power BI?

Embedding Analytics is an official Microsoft feature that allows you to embed reports, dashboards, and other Power BI artifacts directly into web applications and custom portals, securely, in a controlled manner, and without requiring end users to have individual Power BI licenses.

In practice, Embedding Analytics allows you to build (or hire) your own web portal, where Power BI reports appear embedded, as if they were part of your application. The end user accesses your portal, logs in with the credentials you define (corporate email, Gmail, or any other method), and views the reports without even knowing that Power BI is behind it all.

Embedded, "Publish to Web," and "Embed Report": what are the differences?

Although all three options allow you to embed reports in websites, SharePoint, email, Teams, and other channels, they are very different in terms of security, cost, and control. See the comparison:

1. Publish to Web

This is the simplest way, but also the most dangerous. The report becomes completely public, without any access control. Anyone who has the link can view the data, including Google, which indexes these reports in simple searches, even if the link has never been published anywhere. There is no authentication, no RLS, no OLS, and no audit of who accessed it. Use this only for truly public data, such as election results or open economic indices.

Even if you try to block access with a password on the portal hosting the iframe, this type of protection is easily bypassed in a few seconds using the browser's Developer Tools. The person will have unrestricted access to the data published in the report.

2. Embed Report (via HTML/iFrame code)

This option allows you to incorporate the report into websites, SharePoint, Teams, etc., while maintaining all Power BI security controls: permissions, RLS, OLS, and access audits. But the problem is clear: all users who access the report embedded this way still need an active Pro or PPU license. Furthermore, you cannot control report elements via programming language, such as creating or editing visuals dynamically, changing themes, creating or deleting pages, etc.

3. Embedding Analytics (Integrated Analytics via dedicated capacity)

This is the most complete feature. It allows you to view reports securely, with RLS, OLS, permission control, IP blocking, access auditing, and full programmatic control (filters via code, theme switching, page navigation, creation and editing of visuals), without users needing a Power BI license. Licensing occurs via dedicated capacity (Fabric or Power BI Embedded), not per user. It is the only option that delivers all these benefits at the same time.

The Two Report Embedding Models

Within Embedding Analytics, Microsoft defines two embedding models. Choosing the wrong one can mean both a poor experience and a violation of the licensing agreement:

User Owns Data: Embed for your Organization

This is the simplest and most direct model. Each end user authenticates to Power BI with their own corporate account, via Entra ID (Azure AD).

The application acts as a bridge, but the experience is personalized per user, and each person needs a Power BI Pro license (or access to a workspace in Premium capacity).

Correct scenarios for this model:

• Internal applications for a company's employees.
• Corporate solutions that follow internal security and identity policies.
• Internal users authenticated in Entra ID with Pro or P SKU licensing.

This model is not suitable for external customers or for scenarios where the goal is to eliminate the cost of per-user licenses. Do not try to use User Owns Data with external users or share credentials and tokens manually.

App Owns Data: Embed for your Customers

This is the ideal model for ISVs (Independent Software Vendors) and SaaS solutions, and it is what enables significant cost reduction.

Here, it is not the end user who authenticates to Power BI, but the application itself, using a Service Principal (a technical identity in Azure AD). The application generates an embed token with minimal scope for each session and delivers the rendered report to the user, who never needs to have a Microsoft account or a Pro license.

Characteristics of this model:

• End users do not need a Power BI Pro or PPU license.
• End users do not need a Microsoft account (they can use Gmail, their own corporate email, login with password, corporate SSO, etc.).
• Permission control, RLS, and visibility are handled within the application, via an embed token.
• Mandatorily requires a dedicated capacity (Fabric or Power BI Embedded) in production.
• Report content must be in a non-personal workspace associated with the capacity.
• Users can even create and edit reports through the portal without needing a Pro license, as documented by Microsoft.

Can I Use a Pro or PPU License to Embed in Production?

This is one of the most frequent questions, and the answer must be direct: no. Technically, it is possible to generate embed tokens with a Pro or PPU account (called a "Master Account"), but Microsoft itself is explicit in the official documentation:

"Embed tokens with Pro or Premium Per User (PPU) license are intended for development testing, so a Power BI master account or service principal can only generate a limited number of tokens. Purchase a capacity for embedding in a production environment. There is no limit to how many embed tokens you can generate when you purchase a capacity."

Source: Microsoft official documentation: "Move your embedded application to production"

In other words, using Pro/PPU to embed is only permitted in development and testing environments. In production, with real users accessing it, Microsoft requires a dedicated capacity.

Using a Pro license for this in production:

• Violates Power BI terms of use and Microsoft Product Terms.
• Can result in fines, sanctions, and compliance audits by Microsoft.
• Has a limit on tokens that, when reached, causes reports to stop loading.
• Creates serious security risks, as the use of Pro/PPU + external embedding can be exploited as a data exfiltration vector. If a token leaks, anyone can access all reports of all customers in that tenant.
• The use of a Master Account requires storing a login and password, which creates a risk of credential leakage.

Dedicated Capacities: what are they and what are the options?

Dedicated capacities are exclusive computational resources, provisioned in Azure, that license the use of Embedding Analytics and allow you to generate embed tokens unlimitedly.

Without a contracted capacity, using only a Pro or PPU account, you have a limited amount of tokens. After a while, this limit is reached, and Power BI no longer allows you to embed reports.

For these reasons, having a capacity is mandatory for any use in production.

There are three types of capacities:

Microsoft Fabric (F SKUs): the most modern option

Fabric capacities are the newest and most complete generation. In addition to supporting Embedding Analytics, they enable all other Microsoft Fabric workloads: Data Engineering, Data Science, Data Warehouse, Real-Time Analytics, and much more. They are the recommended option for new projects.

Advantages of F SKUs:

• Charged per hour of execution (per-second granularity).
• Can be paused at any time, stopping the billing.
• Newer, more flexible, and with more features integrated into the Microsoft ecosystem.
• Start from F2 (smaller and cheaper), reducing the entry cost.
• 60-day free trial period available from Microsoft (F64), allowing you to run a complete PoC without capacity costs.
• Any F SKU size supports Embedding Analytics, as documented by Microsoft on the "Understand Microsoft Fabric licenses" page.

Attention: Fabric uses the concepts of smoothing, bursting, and throttling, which change the simple logic of "pause = save." This will be explained in detail later in this article.

Power BI Embedded (A SKUs): pay-as-you-go option

Available since 2017, A SKU capacities (A1 to A6) are provisioned directly in Azure and charged per hour of use. They are the most traditional, stable, and reliable option for Embedding scenarios.

Depending on the region and size, they can be much cheaper than F SKUs (Fabric) for certain usage profiles.

Characteristics:

• Charged per hour of execution. Pausing the capacity completely suspends billing.
• More predictable for continuous use, as they do not have the complexity of Fabric's smoothing.
• The savings calculation is simple: number of hours turned on × cost per hour of the capacity.
• Widely supported by all Embedding tools and portals on the market.

Premium Per Capacity (P SKUs): discontinued

P SKU capacities were the premium version of Power BI before Fabric. They have been discontinued by Microsoft and are no longer available for new contracts. The initial cost was approximately R$ 32,000/month (~US$ 5,700/month) (P1 tier), which made them unfeasible for most companies. P SKUs have been replaced by Fabric's F SKUs.

If you already have a contracted Premium capacity (P tier), it includes Embedded functionality from the P1 tier onwards and can be used with Embedding portals normally.

Premium Capacity (EM SKUs): for Internal Applications and SharePoint

EM SKUs are a Power BI Premium capacity tier created specifically for the embedding for your organization (User Owns Data) scenario: internal corporate applications, intranets, SharePoint Online, Teams, and PowerPoint. Unlike A SKUs (purchased via the Azure portal, billed hourly, and pausible), EM SKUs are purchased through Microsoft's Volume Licensing agreements (Enterprise Agreement or CSP), with an annual commitment and fixed monthly billing.

The main advantage of EM compared to simply buying Pro licenses for every employee is allowing users with a free Power BI account to view reports embedded in SharePoint Online, without needing to assign a Pro license to each one.

Characteristics of EM SKUs:

• Cannot be paused: Billing is fixed monthly, regardless of actual usage time. There is no option to pause to reduce costs during low-usage hours.
• Contracted via corporate licensing: Purchased through Microsoft volume licensing agreements (Enterprise Agreement or CSP), not directly through the Azure portal like F and A SKUs. The EM1 and EM2 tiers are not available for individual purchase.
• Compatible with the Power BI Web Part for SharePoint Online: Allows users with a free Power BI account to view reports embedded in SharePoint without needing a Pro license.

Computational capacity equivalencies and estimated reference values (EM SKUs are acquired exclusively via volume contracts and do not have an officially published price list; the values below are estimates based on market information and may vary according to exchange rates, contracting channels, and negotiations):

• EM1 (1 v-core): equivalent to F8 and A1. ~R$ 4,070/month (~US$ 740/month).
• EM2 (2 v-cores): equivalent to F16 and A2. ~R$ 8,131/month (~US$ 1,480/month).
• EM3 (4 v-cores): equivalent to F32 and A3. ~R$ 16,283/month (~US$ 2,960/month).

Embedding in SharePoint Online: The Native Power BI Web Part

For companies that use Microsoft 365 and SharePoint Online as a corporate intranet, there is a native way to embed reports directly into SharePoint pages: the Power BI Web Part for SharePoint Online. This feature allows employees to view interactive reports without leaving the SharePoint environment, integrating analytics directly into daily corporate pages and portals.

It is important to understand the differences between this approach and the full Embedding Analytics described in the previous sections, as each has distinct characteristics, license requirements, and use cases.

SharePoint Web Part vs. Full Embedding Analytics: key differences

The native SharePoint Web Part uses the User Owns Data model. This means that each user authenticates with their own Microsoft account and Power BI applies security controls based on that identity.

Power BI Web Part for SharePoint Online (User Owns Data):

• Each user authenticates with their own organizational Microsoft account.
• Security and RLS are applied automatically based on the logged-in user's identity.
• No development required: simple configuration via the SharePoint interface in a few minutes.
• Offers no programmatic control: it is not possible to apply filters via code, change themes, or switch pages dynamically.
• Accepts only organizational Microsoft accounts from the tenant. Does not accept Gmail or external emails.
• Requires a Power BI Pro, PPU license, or for the workspace to be in an EM or P SKU capacity.

Full Embedding Analytics (App Owns Data), with a dedicated portal:

• The application authenticates to Power BI via Service Principal, not the end user.
• End users do not need a Microsoft account or a Power BI license.
• Requires development of a custom portal or the purchase of a ready-made solution.
• Offers full control via SDK: dynamic filters, themes, programmatic exports, and much more.
• Any F SKU or A SKU is sufficient, with no need for EM or P.
• Suitable for external portals, clients, partners, and SaaS scenarios.

Licensing for Viewing in SharePoint: The EM SKU Difference

For a user to view a report embedded via the SharePoint Web Part, one of the following conditions must be met:

• The user has a Power BI Pro or PPU (Premium Per User) license; or
• The workspace containing the report is associated with an EM SKU or P SKU capacity.

It is precisely for this scenario that EM SKUs were created: to allow employees without a Pro license to access reports embedded in the intranet or SharePoint, without the need for a P SKU (which starts at ~R$ 32,000/month) or an F64 (whose computational capacity is equivalent to P1).

How to Embed a Report in SharePoint Online

The process requires no development and can be completed in a few minutes:

1. Open the report in the Power BI service (app.powerbi.com).
2. Click File, select Embed report, and then SharePoint Online.
3. Copy the URL displayed in the dialog box.
4. Access the desired SharePoint Online page and click Edit.
5. Add a new Web Part, locate the Data Analysis section, and select Power BI.
6. Click Add report and paste the copied URL. The report will automatically load in the Web Part.
7. Click Publish to make the page visible to other users.

After embedding, the Web Part offers the following settings:

• Default page: defines which report page is displayed when loading the Web Part.
• Display: adjusts how the report adapts to the SharePoint page width.
• Navigation pane: shows or hides the navigation pane between report pages.
• Filter pane: shows or hides the side filter pane.

Limitations and Restrictions of the SharePoint Web Part

• No support for B2B guest users: External users added via Azure B2B cannot view reports in the SharePoint Web Part.
• No URL filters: It is not possible to pass filters via URL parameters to the Power BI Web Part in SharePoint.
• Modern Pages only: Classic SharePoint (on-premises) is not supported.
• No programmatic control: It is not possible to apply filters via code, export via API, or customize the experience dynamically as in the Power BI Embedded SDK.
• App access requires pre-installation: To display content from a Power BI App in SharePoint, the user must install the app in the Power BI service before they can view it on the page.
• MFA may cause authentication errors: If the environment requires MFA and the user did not authenticate with MFA when entering SharePoint, a token error may appear. The solution is to sign out and sign in again with the configured MFA device.
• Copilot available with Premium capacity: You can enable Copilot by checking the option when generating the embed link (File > Embed report > SharePoint Online). Requires Copilot to be enabled in the tenant and the workspace to be in a paid Premium or Fabric capacity.

Do I need F64 to use Embedding Analytics without a Pro license?

This is one of the biggest points of confusion in the market, so let's clarify it once and for all.

It is true that users can access reports directly through the Power BI portal (app.powerbi.com) without a Pro license, provided the workspace is associated with an F64 capacity or higher (equivalent to the old P1). This is a specific benefit restricted to direct access via the Microsoft portal.

But when we talk about Embedding Analytics, the rules are completely different:

• Any F SKU size (F2, F4, F8, F16...) allows viewing reports via an Embedding portal without needing a per-user Pro license.
• Any Power BI Embedded SKU (A1 to A6) also works for this scenario.
• Microsoft explicitly documents on the "Understand Microsoft Fabric licenses" page: for the "App Owns Data" scenario, any F SKU can be used and end users do not need a license.
• The "Capacity and SKUs in Power BI embedded analytics" page confirms: "Power BI embedded analytics requires a capacity (A, EM, P, or F SKU) to publish embedded Power BI content."

In other words, you do not need F64 to eliminate the need for Pro licenses for your users. You need any dedicated capacity, combined with a viewing portal that uses the App Owns Data model. The F64 difference is exclusive to the scenario of direct access to app.powerbi.com without an individual license.

How does cost reduction work in practice?

The mechanics of cost reduction are simple: instead of each user accessing the Power BI portal (which requires an individual license), they access the Embedding portal, which does not require a Microsoft account or a Pro license. The contracted capacity serves everyone, regardless of how many users exist. The cost of the capacity does not scale with the number of users.

Let's look at a concrete example. Imagine a company with 200 users who need to access Power BI reports:

Current scenario, with Pro per user: 200 licenses × ~R$ 95/month = R$ 19,000/month (~US$ 3,450/month)

Scenario with Embedding Analytics:

• F8 capacity (sufficient for many mid-sized scenarios): ~R$ 2,000 to R$ 3,000/month (~US$ 360 to US$ 545/month)
• Viewing portal (like Power Embedded): ~R$ 5/user/month = R$ 1,000/month for 200 users (~US$ 180/month)
• Pro licenses only for those who publish reports (e.g., 5 developers): ~R$ 475/month (~US$ 85/month)
• Total estimated: R$ 3,475 to R$ 4,475/month (~US$ 630 to US$ 810/month)

This represents savings between 75% and 80%. And the greater the number of users, the greater the percentage savings, since the capacity cost is fixed and does not grow with the number of users.

From how many users is it worth it?

For Power BI Pro licenses, in companies where reports do not need to be available 24 hours a day, starting from approximately 15 users, it is already possible to save around 50% compared to the cost of Pro licenses. If you use a Premium Per User (PPU) license, the savings can reach 76% with just 15 users.

In scenarios where reports need to be available 24 hours a day (capacity on all the time, without pauses), from approximately 30 users, Embedding Analytics becomes more financially advantageous.

Does pausing capacity reduce costs?

A very common question: if I pause the capacity outside business hours, do I save money?

The answer depends on the type of capacity used, and in the case of Fabric, also on your usage pattern:

For Power BI Embedded (A SKUs): Pausing always reduces costs, as there is no smoothing. Billing is strictly per hour of use. The savings calculation is simple and predictable: number of hours on × cost per hour. It makes sense to pause whenever there are no reports in use.

For Microsoft Fabric (F SKUs): The situation is more complex. Savings when pausing do not always happen because of the concepts of smoothing, bursting, and throttling.

Smoothing, Bursting, and Throttling: Understanding What They Are

Smoothing:

Smoothing allows workloads to use resources beyond the provisioned limit during demand spikes, distributing resource consumption over time. To achieve this, Fabric uses the concept of "proportional pre-allocation of future usage." This allows you to use capacity based on average usage, not peak usage.

In practice:

• When you run background tasks, such as dataset refreshes, notebooks, or pipelines, the system amortizes and distributes the cost over the next 24 hours.
• For interactive activities (browsing reports), there is a minimum smoothing of just 5 minutes.
• If you pause the capacity before the smoothing completes, the system understands that you have interrupted the "payment window" and will charge separately for the hours that were already pre-allocated. In some scenarios, this can even double the estimated cost if you only consider the hours the resource was active without accounting for smoothing.

Bursting (Elastic Capacity):

Allows workloads to temporarily use more resources than the base SKU, improving performance during spikes. Each SKU has a different burst factor (for example, F2 may have a burst of up to 32x, F8 may have up to 12x). This is useful for absorbing spikes without needing to permanently provision a larger capacity.

Throttling:

Occurs when the average use of CUs (Capacity Units) exceeds the SKU's smoothed limits. Ongoing operations are not interrupted; throttling only applies to upcoming operations. Throttling happens in progressive stages:

1. Interactive Delay: after 10 minutes of accumulated overload, interactive operations begin to experience delays.
2. Interactive Rejection: after 60 minutes of accumulated overload, interactive operations are rejected.
3. Background Rejection: after 24 hours of accumulated overload, background operations are rejected.

When it makes sense to pause Microsoft Fabric:

• Outside of fixed pipeline execution and data refresh times (for example, from midnight to 6 AM, when there are no scheduled refreshes).
• When capacity usage is mostly composed of interactive actions (viewing and browsing reports), with little or no background processing.
• When the background percentage in the Fabric Capacity Metrics report is low before pausing.
• Always analyze and track capacity consumption in the Azure Cost Management screen. Starting from the second day after changes to pause schedules, it is possible to analyze the daily cost to verify if savings are actually occurring.

When it might make more sense to leave it on 24x7:

In many scenarios, especially when there are frequent data refreshes and continuous usage, it may make more sense to purchase a Microsoft instance reservation (discount for annual commitment) and leave the capacity on all the time, rather than pausing and potentially generating unexpected smoothing charges.

What happens when the capacity is paused:

While the capacity is paused, no one can access the reports, not even users with a Pro license accessing directly through the Power BI portal (app.powerbi.com). Datasets are also not refreshed. This is a critical planning point.

Availability Models: 24x7, 14x6, and 12x5

Power BI Embedded and Fabric billing is calculated based on the hours the capacity was active. Since both allow you to pause capacity, there are different availability strategies. The most common are:

• 24x7: capacity available 24 hours a day, 7 days a week. No pauses. A scenario for operations that need reports available at any time.
• 14x6: capacity available 14 hours a day, 6 days a week (Monday to Saturday). Represents a 53% saving compared to 24x7. Meets the needs of most corporate clients.
• 12x5: capacity available 12 hours a day, 5 days a week (Monday to Friday). Represents a 67% saving compared to 24x7. Suitable for companies with usage strictly during business hours.

These are just examples. Actual schedules are defined according to each company's usage profile. Tools like Power Embedded offer automatic pause and startup management for capacity, and can also start automatically when a user tries to access a report outside defined hours, and pause again after a period of inactivity configurable by the administrator.

Capacity Above the Limit: What to Do?

If the environment starts showing constant overloads (error messages, blocks on model updates, or report viewing), some measures can help before increasing the SKU:

• Optimize high-capacity-consuming DAX measures.
• Avoid calculated columns and calculated tables in the model whenever possible.
• Reduce the number of visuals per page (the recommendation is no more than 10).
• Optimize dataset modeling: avoid N:N relationships and bidirectional filtering.
• Identify and remove unused columns and tables in the model.
• Pre-aggregate data before importing it into Power BI.
• Optimize M code (Power Query) ensuring that Query Folding is occurring.
• Use incremental data loading instead of full refreshes.
• Evaluate the use of DirectQuery or DirectLake for very large data volumes.
• Separate large datasets into different capacities, distributing the load.
• Evaluate whether it is necessary to increase the SKU or split workloads across multiple capacities.

Risks of Solutions That Violate Licensing

There are embedding solutions on the market that attempt to reduce costs in ways not supported by Microsoft. The two most common and dangerous practices are:

1. Use of Pro or PPU licenses in production (App Owns Data)

As previously explained, Pro and PPU are strictly for development and testing. In production, this violates Microsoft's licensing terms and can result in contractual penalties, audits, service suspension, and legal risks.

2. Multi-tenant SaaS with a single tenant and Service Principal shared among all clients

Another common practice for cost reduction is consolidating multiple clients into a single tenant controlled by the vendor, with a single Service Principal and a shared capacity. In this model, the client has only one user to access and publish reports, rather than being the owner of the information with all the audit and security controls of their own environment.

Although technically possible, this practice creates critical risks:

Security and isolation risks:

• Non-existent isolation: A single technical Service Principal for all clients means: no identity segregation, no real RBAC per client, no granular access control per organization, and no Conditional Access per company. Any RLS configuration error can expose one client's data to another.
• Cascading compromise: If the token or credential leaks (via logs, browser, proxy, or DevTools), anyone has access to all reports for all clients in that tenant. If someone leaves the vendor's company with access to the Service Principal, all clients are compromised simultaneously.
• No audit for the client: When the client does not own the tenant, they cannot see access logs, do not control Purview, do not control Microsoft Defender for Cloud Apps, and cannot prove compliance in LGPD/GDPR audits.
• Zero Trust violated: Microsoft recommends isolation by tenant or capacity, identity control via Entra ID, and architectural multi-tenant segregation as best practices for corporate scenarios.

Compliance and LGPD/GDPR risks:

• The client ceases to be the Data Controller and Tenant Owner, transferring legal responsibility to the vendor without adequate controls.
• Under GDPR/LGPD, this may characterize processing without the controller's oversight, increasing the hiring company's legal liability.
• It makes certifications such as SOC 2, ISO 27001, Microsoft licensing audits, and RBAC, Purview, and Microsoft Defender controls unfeasible.

Licensing risks:

• Violation of Microsoft Product Terms and the licensing agreement.
• Compliance audits and contractual fines by Microsoft.
• Suspension of the service or tenant, impacting the entire company operation.
• Legal and reputational risk for the hiring organization.

Common Errors When Implementing the App Owns Data Model

In addition to the prohibited practices above, there are two common patterns of incorrect implementation worth highlighting:

Error 1: Portal hosting client reports in the ISV's tenant

• A single workspace per client within the vendor's tenant.
• A capacity shared among all clients.
• Service Principal controlled by the vendor, not the client.
• Access segmented only by RLS or token filters.
• The client has no real control over their reports.

Risks: violation of licensing rules, possible contractual infringement with Microsoft, risk of account suspension, and data from multiple clients under the control of a single tenant (security and privacy risk).

Error 2: Use of a Master Account with a Pro license for all reports

• The application uses a generic account with a Pro license to generate embed tokens.
• Does not use a Service Principal (an obsolete practice not recommended by Microsoft).
• No use of dedicated Premium capacity.
• End users access without a license, in violation of licensing.

Additional security risks: the need to store login and password (with risk of leakage), tokens generated with a human user's permissions (without granular authentication or controlled scope), and if tokens are intercepted, anyone can access the embedded content.

What Do You Need to Use Embedding Analytics?

To implement Embedding Analytics in the correct model (App owns data), you need the following prerequisites:

• A dedicated capacity: Fabric F SKU or Power BI Embedded A SKU, contracted through the Azure portal directly with Microsoft or through a Microsoft partner.
• A non-personal Power BI workspace: The reports to be embedded must be in a workspace associated with the capacity. Personal workspaces are not supported for Embedding.
• A Service Principal: A technical identity created in Azure AD (Entra ID) with permissions to access workspaces and generate embed tokens. The Service Principal should have access only to the necessary workspaces, with minimum permissions.
• A viewing portal: Microsoft provides the APIs but does not offer a ready-made portal. You need to develop your own web application or hire a ready-made SaaS solution.
• Pro license for developers: Users who publish reports to the Power BI service still need a Pro or PPU license. Only users who view through the Embedding portal do not. An alternative to also eliminate this dependency is to use Azure DevOps for automatic publishing via CI/CD.
• Azure account: To create the capacity, you need an Azure account with permissions to create resources. If your company does not have an Azure account, you can create one for free, including initial credit from Microsoft.

From the perspective of technical configurations in Azure/Entra ID for installation, typically the following are required:

• User account with permission to create Fabric or Embedded capacity in Azure.
• User account with permission to create groups and Service Principals in Entra ID.
• User account that holds the "Fabric Administrator" role to access the Power BI admin portal and configure Service Principal permissions.

How Does the Report Publishing Process Work?

The flow for publishing and making reports available in Embedding Analytics is practically the same as that which already exists in the traditional Power BI service. No significant change in the report creation process is required:

1. The BI analyst opens Power BI Desktop and creates or edits the report normally.
2. The analyst publishes the report to the desired workspace in the Power BI service (app.powerbi.com), using their Pro or PPU license.
3. The Embedding portal administrator imports the report from the Power BI workspace into the system.
4. The administrator assigns access permissions to the report, via groups or individual users.
5. The administrator configures RLS rules for the dataset, if necessary.
6. Users access the report through the viewing portal, with their credentials configured on the platform.

End users do not need to install Power BI Desktop, create a Microsoft account, or have any knowledge of Power BI. For them, the reports appear within the company portal, as part of the application.

LGPD and Privacy in Embedding Analytics

A point frequently questioned is about compliance with the LGPD (General Data Protection Law) and the European GDPR in the use of Embedding portals. The positive answer depends on the architecture used.

In the correct model (App owns data, with reports in the client's own tenant):

• The process of embedding reports does not require the loading or reading of any company data by the portal. All data remains stored on Power BI servers, in the company's own tenant.
• The portal only makes an HTTP call to the Power BI API, which reads the metadata of the reports and semantic models in the client's tenant and displays them on the screen. Data never travels through the portal server.
• The only data stored by the portal is the names and emails of registered users, for access management.
• All communication is encrypted end-to-end via SSL/HTTPS.
• The company remains the Data Controller of its own data, maintaining all audit, Purview, Defender, and compliance controls.

In the incorrect model (vendor's tenant, shared Service Principal), the company loses control over its data and may have serious difficulties demonstrating compliance with the LGPD in an eventual audit.

Build Your Own Portal or Hire a Ready-Made Solution?

This is an important decision. Microsoft provides Power BI Embedded APIs for any company to develop its own portal, but the real complexity of doing this correctly is much greater than it appears in the documentation:

• Implementation of authentication with Azure AD (Entra ID) and generation of embed tokens with Service Principal.
• Management of users, groups, permissions, and programmatic RLS.
• Responsive, accessible user interface compatible with multiple browsers and mobile devices.
• Management of application server, database, and cloud infrastructure.
• Continuous maintenance to keep up with changes in Microsoft APIs (which are frequent).
• Technical support for end users and report developers.
• Management of capacity pausing and starting.
• Application security (pentest, secret management, Azure Key Vault, etc.).

For a company with 100 users, a basic portal (just login, simple permissions, and viewing) easily demands 100 or more hours from an experienced developer, not counting infrastructure, maintenance, and continuous evolution. Advanced features like generative AI, multi-language support, TV mode, email report subscriptions, SSO, Entra ID synchronization, external APIs, and detailed auditing multiply this effort significantly.

The alternative is to hire a pre-built SaaS solution, with all of this available immediately, maintained and evolved continuously by the provider, with availability SLAs and specialized support.

Power Embedded: A Recommended Platform

An option that I recommend and know closely is Power Embedded. I had the opportunity to follow its development from the beginning, during my time at Power Tuning, and I can say with authority that it is a serious platform, technically solid, and with a correct architecture from the perspective of Microsoft licensing and security.

From an architectural standpoint, Power Embedded operates on the App owns data model with complete isolation per client:

• Each client has their own Microsoft Entra ID tenant.
• Each client has their own Premium capacity (Power BI Embedded or Fabric).
• Each client has their own workspaces with reports, associated with their own capacity.
• A Service Principal is created directly within the client's tenant (with their consent), with permissions only in the workspaces used in the portal.
• Power Embedded authenticates using the client_id + secret of the client's Service Principal, generates the embed token with minimum scope, and applies security and RLS based on the client's settings.
• There is no hosting of reports in the Power Tuning tenant; access and embedding occur using the Service Principal of the client's own tenant.

This is 100% compliant with the "App owns data" model documented by Microsoft, and ensures that even as a multi-client portal, each tenant has its own isolated embed instance.

From an internal infrastructure and security perspective:

• Architecture based on self-managed SaaS resources in Azure, with 99.99% high availability, automatic failover, and automatic backups.
• Periodic pentests, both automated and manual by hired security experts.
• The entire cloud environment protected by Microsoft Defender for Cloud.
• Access to Azure resources blocked from the internet, accessible only via VPN.
• Encrypted communication via SSL (HTTPS) certificates.
• Power BI access keys stored encrypted with RSA-OAEP, with individual keys per client in Azure Key Vault.

Some of the features available on the platform:

• Reduction of up to 90% in Power BI licensing costs.
• Users access with any email (corporate, Gmail, etc.), without a Microsoft account, without installing apps.
• All workspaces become Premium, unlocking up to 48 refreshes per day, datasets over 1 GB, XMLA Endpoint, hybrid tables, deployment pipelines, and Git versioning.
• Full white-label: visual identity of your company or each client, including custom URL.
• Multi-language (6 languages supported).
• Automatic synchronization of users and groups via Entra ID (SSO).
• Generative AI (Power Pilot): natural language questions directly about the data, with dynamic table and chart generation.
• RLS, OLS, and detailed login and access audits.
• TV mode for reports cycling automatically on monitoring dashboards.
• Automatic capacity management: turns on when there is access, turns off after configurable inactivity.
• Export to CSV, Excel, PDF, image, and PowerPoint.
• APIs for automation and integration with external systems.
• Responsive reports: native support for mobile layout, no need to install apps.
• Deployment within 16 business hours after commercial approval, installation takes 20 to 60 minutes.
• 30-day free trial (in addition to the 60 free days of F64 capacity provided by Microsoft).

It is not mandatory to use Power Embedded specifically. The important thing is that any solution you use respects the correct architecture: App owns data, Service Principal per client tenant, dedicated capacity per client, and total isolation between clients. But if you want a ready-made option, tested in production, with specialized support and constantly updated, Power Embedded is my recommendation.

Final Considerations

Embedding Analytics is one of the most powerful and underutilized features of the Power BI ecosystem. It solves three problems at once: it reduces licensing costs, improves the end-user experience, and increases security control over who accesses what.

The most important points to remember:

• Embedding Analytics is a Microsoft feature; it is not the name of a specific platform.
• The correct model to eliminate per-user licenses is App owns data, with dedicated capacity.
• Pro and PPU are for development and testing; in production, Microsoft requires dedicated capacity.
• You do not need F64 to use Embedding Analytics without per-user licenses. Any F SKU or A SKU works.
• The developers who publish reports still need a Pro license. Users who view through the Embedding portal do not.
• Solutions that share a single tenant and Service Principal among multiple clients create serious security, compliance, and licensing risks.
• Microsoft does not provide a ready-made viewing portal. You need to develop or hire one.
• In Fabric, pausing capacity does not always generate savings. Understand smoothing before defining your pause strategy.
• With availability models like 14x6 or 12x5, it is possible to save from 53% to 67% over the cost of a 24x7 capacity.
• Starting from just 15 Pro users, Embedding Analytics can already be more economical.

If you are evaluating implementing this strategy in your company, I recommend starting with the 60-day free trial of Microsoft Fabric (F64). During this period, you can run the entire proof of concept and measure the actual capacity consumption of your environment before defining which SKU to contract for production.

References

All technical content in this article is based on official Microsoft documentation. Below are the main links for consultation and further study:

• Power BI embedded analytics — Microsoft Learn — Official overview of Embedding Analytics, embedding models, and licensing requirements.
• Embed for your customers (App Owns Data) — Microsoft Learn — Detailed breakdown of the App Owns Data model with Service Principal.
• Embed for your organization (User Owns Data) — Microsoft Learn — Detailed breakdown of the User Owns Data model with per-user authentication.
• Move to production (Power BI Embedded) — Microsoft Learn — Official documentation confirming that tokens with Pro/PPU are exclusive for development and that a capacity is mandatory in production.
• Capacity and SKUs in Power BI embedded analytics — Microsoft Learn — Comparative table of SKUs, licensing requirements per embedding scenario, and confirmation that App Owns Data does not require licenses for end users.
• Power BI Embedded FAQ — Microsoft Learn — Official technical FAQ, including token limits per license type.
• Embed Power BI content with service principal — Microsoft Learn — How to configure and use Service Principal in the App Owns Data model.
• Usage scenarios: embed for your customers — Microsoft Learn — Implementation planning guide with licensing requirements for the embed for customers model.
• Understand Microsoft Fabric licenses — Microsoft Learn — Complete breakdown of F SKUs, embedding scenarios by SKU type, and per-user licensing requirements.
• Compute capacity smoothing and throttling in Microsoft Fabric — Microsoft Learn — Technical documentation on smoothing, bursting, and throttling in Fabric capacities.
• Embed a report web part in SharePoint Online — Microsoft Learn — Official documentation on how to embed Power BI reports in SharePoint Online, including licensing requirements and Web Part settings.

Well folks, I hope this article has helped clarify Embedding Analytics in Power BI in a complete and practical way.

Best regards and see you next time!