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

Hey everyone!

If you work with Power BI and have ever needed to share reports with dozens or hundreds of users, especially those external to your organization, you've probably felt the burden of individual licenses. Power BI Pro, Premium per User (PPU)... the cost quickly adds up. But there's an official, completely legal, and much more economical alternative from Microsoft: Embedding Analytics.

In this article, I'll cover the entire topic from scratch: what Embedding Analytics is, how it works, the available licensing models, the dedicated capacities involved, the technical concepts of Fabric smoothing, bursting, and throttling, the risks of solutions that deviate 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 in 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: Each user who needs to access reports incurs a monthly license cost. For small internal teams, this is fine. But when you need to share with clients, 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 lacks the necessary context to navigate independently.
• External access limitations: Users external to your organization need to be added as guests in Azure AD, which adds 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 Power BI reports, dashboards, and other artifacts directly into custom web applications and portals, securely, controllably, and without requiring end-users to have individual Power BI licenses.

In practice, Embedding Analytics allows you to build (or contract) 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 embedding reports into 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, but also the most dangerous, method. The report becomes completely public, without any access control. Anyone with 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, no audit of who accessed it. Use 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 code/iFrame)

This option allows you to embed 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 embedded report in this way still need an active Pro or PPU license. Furthermore, you cannot control report elements via programming language, such as dynamically creating or editing visuals, changing themes, creating or deleting pages, etc.

3. Embedding Analytics (Integrated Analytics via dedicated capacity)

This is the most complete feature. It allows viewing reports securely, with RLS, OLS, permission control, IP blocking, access auditing, and full programmatic control (filters via code, theme changes, page navigation, visual creation and editing), 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 simultaneously.

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: Embedding for Your Organization

This is the simplest and most straightforward 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 company 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 clients or for scenarios where the goal is to eliminate the cost of per-user licenses. Do not attempt to use User Owns Data with external users or share credentials and tokens manually.

App Owns Data: Embedding 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 a Microsoft account or 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 managed within the application, via the embed token.
• 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 for Embedding in Production?

This is one of the most frequent questions, and the answer needs to 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 a 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's no limit to how many embed tokens you can generate when you purchase a capacity."

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

In other words, using Pro/PPU for embedding is only allowed in development and testing environments. In production, with real users accessing, Microsoft requires a dedicated capacity.

Using a Pro license for this in production:

• Violates the Power BI terms of use and Microsoft Product Terms.
• Can result in fines, sanctions, and compliance audits by Microsoft.
• Has a token limit 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 clients in that tenant.
• The use of a Master Account requires storing 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 generating embed tokens unlimitedly.

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

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

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:

• Billed per hour of execution (per-second granularity).
• Can be paused at any time, stopping 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 a complete PoC to run at no capacity cost.
• Any size of F SKU supports Embedding Analytics, as documented by Microsoft on the page "Understand Microsoft Fabric licenses".

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 SKUs (A1 to A6) are provisioned directly in Azure and billed 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 significantly cheaper than F SKUs (Fabric) for certain usage profiles.

Characteristics:

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

Premium per Capacity (P SKUs): discontinued

P SKUs 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,760) (P1 tier), which made them unfeasible for most companies. P SKUs have been replaced by Fabric F SKUs.

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

Do I Need F64 to Use Embedding Analytics Without a Pro License?

This is one of the biggest confusions 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 through the Microsoft portal.

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

• Any size of F SKU (F2, F4, F8, F16...) allows viewing reports via an Embedding portal without needing a Pro license per user.
• Any Power BI Embedded SKU (A1 to A6) also works for this scenario.
• Microsoft explicitly documents on the page "Understand Microsoft Fabric licenses": for the "application owns data" (App Owns Data) scenario, any F SKU can be used, and end-users do not need a license.
• The page "Capacity and SKUs in Power BI embedded analytics" 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 difference of F64 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 there are. The cost of 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,420)

Scenario with Embedding Analytics:

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

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

From how many users is it worthwhile?

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

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

Does Pausing Capacity Reduce Cost?

A very common question: if I pause 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 cost, as there is no smoothing. Billing is strictly per hour of use. The cost-saving calculation is simple and predictable: hours on × cost per hour. It makes sense to pause whenever reports are not in use.

For Microsoft Fabric (F SKUs): The situation is more complex. Savings from pausing do not always occur, due to the concepts of smoothing, bursting, and throttling.

Smoothing, Bursting, and Throttling in Fabric: Understand What They Are

Smoothing:

Smoothing allows workloads to use resources beyond the provisioned limit during demand peaks, distributing resource consumption over time. To do this, Fabric uses the concept of "proportional pre-allocation of future usage." This allows capacity to be used 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 (report navigation), there is minimal smoothing of only 5 minutes.
• If you pause capacity before smoothing completes, the system understands that you interrupted the "payment window" and will separately charge for the hours that were already pre-allocated. This can, in some scenarios, even double the estimated cost if you only consider the hours on without considering smoothing.

Bursting (Elastic Capacity):

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

Throttling:

Occurs when the average CU (Capacity Units) usage exceeds the smoothed limits of the SKU. Operations in progress are not interrupted; throttling only applies to subsequent 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 fixed hours for pipeline execution and data refreshes (for example, from midnight to 6 AM, when no scheduled refreshes occur).
• When capacity usage is predominantly composed of interactive actions (viewing and navigating reports), with little or no background processing.
• When the background percentage in the Fabric Capacity Metrics report is low before pausing.
• Always analyze and monitor capacity consumption on the Azure Cost Management screen. From the second day after changes in pause scheduling, it is already 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 with frequent data refreshes and continuous use, it may make more sense to purchase a Microsoft instance reservation (annual commitment discount) and leave the capacity on all the time, rather than pausing and potentially incurring unexpected smoothing charges.

What happens when capacity is paused:

While 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 by the hours the capacity was on. As both allow pausing capacity, there are different availability strategies. The most common are:

• 24x7: capacity available 24 hours a day, 7 days a week. No pauses. 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 saving of 53% compared to 24x7. Serves most corporate clients.
• 12x5: capacity available 12 hours a day, 5 days a week (Monday to Friday). Represents a saving of 67% compared to 24x7. Suitable for companies with strictly business-hour usage.

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

Capacity Above Limit: What to Do?

If the environment starts to show constant overloads (error messages, impediments to updating models or viewing reports), some measures can help before increasing the SKU:

• Optimize DAX measures with high capacity consumption.
• Avoid calculated columns and calculated tables in the model, when possible.
• Reduce the number of visuals per page (recommended 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 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 into multiple capacities.

Risks of Solutions That Violate Licensing

In the market, there are Embedding solutions that try 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 already explained, Pro and PPU are strictly for development and testing. In production, it 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 to consolidate multiple clients into a single tenant controlled by the provider, with a single Service Principal and shared capacity. In this model, the client only has one user to access and publish reports, instead of owning the information with all audit and security controls of their own environment.

While 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 misconfiguration 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 of all clients in that tenant. If someone leaves the provider's company with access to the Service Principal, all clients are simultaneously compromised.
• No client audit: When the client does not own the tenant, they do not 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 provider without adequate controls.
• Under GDPR/LGPD, this can characterize processing without controller control, increasing the contracting company's legal responsibility.
• 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 penalties from Microsoft.
• Suspension of service or tenant, impacting the company's entire operation.
• Legal and reputational risk for the contracting 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 provider's tenant.
• A shared capacity among all clients.
• Service Principal controlled by the provider, 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 Master Account with Pro license for all reports

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

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

What 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 only have access to the necessary workspaces, with minimal 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 contract 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 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 required are:

• 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 with the "Fabric Administrator" role to access the Power BI administration portal and configure Service Principal permissions.

How Does the Report Publishing Process Work?

The process of publishing and making reports available in Embedding Analytics is practically the same as in the traditional Power BI service. No significant changes to the report creation process are necessary:

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 the 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 Power BI knowledge. For them, reports appear within the company's portal, as part of the application.

LGPD and Privacy in Embedding Analytics

A frequently asked question is about compliance with LGPD (Brazil's General Data Protection Law) and the European GDPR when using 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 loading or reading any company data by the portal. All data is 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 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 are the names and emails of registered users, for access management.
• All communication is end-to-end encrypted 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 face serious difficulties in demonstrating LGPD compliance in a potential audit.

Build Your Own Portal or Contract 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.
• Capacity pause and start management.
• Application security (pentesting, secrets management, Azure Key Vault, etc.).

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

The alternative is to contract a ready-made SaaS solution, with all of this immediately available, continuously maintained and evolved by the vendor, with an availability SLA and specialized support.

Power Embedded: A Recommended Platform

One option 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 confidently say that it is a serious, technically solid platform with the correct architecture from Microsoft's licensing and security perspective.

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

• 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's Service Principal client_id + secret, generates the embed token with minimal scope, and applies security and RLS based on the client's configurations.
• There is no hosting of reports in the Power Tuning tenant; access and embedding occur using the client's own tenant's Service Principal.

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 infrastructure and internal 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 contracted security specialists.
• 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 certificates (HTTPS).
• 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:

• Up to 90% reduction in Power BI licensing costs.
• Users access with any email (corporate, Gmail, etc.), without a Microsoft account, without installing applications.
• All workspaces become Premium, enabling up to 48 updates per day, datasets over 1 GB, XMLA Endpoint, hybrid tables, deployment pipelines, and Git versioning.
• Complete white-label: your company's visual identity or each client's, including custom URL.
• Multi-language (6 supported languages).
• Automatic synchronization of users and groups via Entra ID (SSO).
• Generative AI (Power Pilot): natural language questions directly on the data, with dynamic table and chart generation.
• RLS, OLS, and detailed login and access audits.
• TV mode for reports automatically cycling on monitoring dashboards.
• Automatic capacity management: turns on when accessed, turns off due to 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 applications.
• Deployment within 16 business hours after commercial approval, installation in 20 to 60 minutes.
• 30-day free trial (in addition to the 60-day free 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, production-tested option with specialized support and constant updates, 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: 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 a per-user license. Any F SKU or A SKU works.
• 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 contract 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 53% to 67% over the cost of a 24x7 capacity.
• 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 deciding which SKU to contract for production.

Official 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 — Details of the App Owns Data model with Service Principal.
• Embed for your organization (User Owns Data) — Microsoft Learn — Details 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 end-user licenses.
• 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 details 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.

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

Best regards and see you next time!