Embedding Power BI in Power Apps and Driving Cross-Filtering

Embedding Power BI inside a canvas app is easy until users expect the report and the app to behave like one product. The real work is deciding which side owns selection, filtering, refresh, and licensing. If you design those boundaries up front, the experience feels intentional instead of bolted on.

The native control is best for contextual analytics

Use the Power BI tile control when the app needs analytics beside a process. In a canvas app, insert the Power BI tile control, choose a workspace, dashboard, and tile, then place it near the records or actions it explains. This is excellent for operational dashboards, KPI tiles, and report visuals that help a user make a decision before submitting an update.

The control is not a full application integration layer. It displays Power BI content and supports user interaction within the embedded content, but it does not make every report event available to Power Fx. Treat it as an analytics surface unless you intentionally add a second integration pattern.

Requirement	Recommended pattern	Notes
Show a KPI tile in an app	Power BI tile control	Fastest and simplest
Filter report from app state	Parameterized report link or embed filter pattern	Validate URL filter syntax carefully
Read report selection in app	Power Apps visual inside Power BI or custom embedded host	Native tile control is not enough
Write back to business data	Canvas controls with Dataverse or connector actions	Do not write through report visuals
Heavy report interaction	Open full Power BI report	Better navigation and performance

Do not oversell the control. Users can view and interact with Power BI content, but app logic still needs a supported data path. That distinction prevents expensive rework.

App selections can drive report filters

The cleanest app-driven pattern is selection → filter → report context. When a user selects a customer, region, asset, or order in the canvas app, store that value in a variable. Then use it to construct a report URL or filter expression for the embedded report experience you support.

For simple contextual navigation, use a button that opens Power BI with a URL filter. The syntax depends on the report model names and column names, so test it with real values and encoding.

Set(varSelectedCustomerId, galCustomers.Selected.CustomerId);
Set(
    varPowerBiUrl,
    "https://app.powerbi.com/groups/me/reports/00000000-0000-0000-0000-000000000000/ReportSection" &
    "?filter=Customers/CustomerId eq '" & EncodeUrl(varSelectedCustomerId) & "'"
);
Launch(varPowerBiUrl);

Use stable keys, not display names. Filter on customer ID, account number, project code, or another durable key. Display names contain punctuation, duplicates, and renamed values. Keys make cross-filtering testable.

If your app hosts a report through a custom component or web resource, pass the selected value as a parameter and let the host apply the Power BI JavaScript filter. That moves advanced embedding work out of Power Fx and into a supported TypeScript boundary.

const filters = [
  {
    $schema: "http://powerbi.com/product/schema#basic",
    target: { table: "Customers", column: "CustomerId" },
    operator: "In",
    values: [selectedCustomerId]
  }
];

await report.setFilters(filters);

Keep the contract small. The app should pass a selected key and maybe a date range. The embedded report should own visuals, measures, and model logic.

Reading Power BI selections back needs the right host

This is where many designs break. A canvas app that simply contains a Power BI tile control should not be expected to read every clicked bar, point, or table row back into Power Fx. If the requirement is Power BI selection → app action, choose an architecture that exposes the selection.

The most common supported pattern is to embed the canvas app inside a Power BI report using the Power Apps visual. In that model, report selections are passed into the app through PowerBIIntegration.Data. The app can read selected rows and use them to populate forms, filter galleries, or submit actions.

ClearCollect(colSelectedFromPowerBI, PowerBIIntegration.Data);
Set(varSelectedAccount, First(colSelectedFromPowerBI).AccountId);
Filter(Orders, AccountId = varSelectedAccount)

Direction matters. Power Apps hosting Power BI is app-led analytics. Power BI hosting Power Apps is report-led action. Both are valid, but they are not interchangeable.

Two-way interaction should have one source of truth

Avoid circular selection logic. If a user selects an account in the app, the report filters. If the user selects a bar in the report, the app updates. That sounds great, but it can create confusing state unless you define the source of truth.

A pragmatic approach is to make the app own operational context and Power BI own analytical context. The app sends the selected business key to the report. The report can send a selected data point back only when the user explicitly chooses an action such as review orders, create task, or open account.

If(
    IsBlank(varSelectedAccount),
    Notify("Select an account before reviewing analytics.", NotificationType.Warning),
    Set(varReportFilterAccount, varSelectedAccount)
)

Make state visible. Show the current filter value in the app. Add a clear filter button. Users should not wonder why a report is narrowed to one account.

Licensing decides whether the design survives rollout

Validate Power BI licensing before the build gets popular. Users viewing embedded Power BI content generally need the right Power BI license, unless the content is served through capacity such as Power BI Embedded or Fabric capacity depending on your organization setup. Power Apps licensing is separate. A premium app license does not automatically grant Power BI report access.

Also validate workspace permissions, row-level security, tenant embed settings, and external sharing rules. A report that works for the maker can fail for every end user because dataset permissions were never assigned.

Security must be enforced in the model. Do not rely on the app hiding a customer picker. Use Power BI row-level security and Dataverse or source-system permissions where appropriate. The embed should respect the user identity and the data model should enforce access.

Performance and refresh are product requirements

Embedded reports compete with app performance. A large report page with many visuals can make a canvas app feel slow, especially on mobile devices. Use focused report pages for embedding: fewer visuals, optimized measures, import or DirectQuery choices made deliberately, and visual interactions trimmed to the scenario.

Refresh is a separate concern. Power Apps might write a Dataverse row immediately, while the Power BI dataset refreshes on a schedule or through DirectQuery. Tell users what is real time and what is refreshed. If they submit an update and expect the tile to change instantly, you need a refresh strategy or a different UI.

Design the embedded surface like a component. Give it a bounded purpose, stable filter inputs, known licensing, and clear refresh behavior. Power BI in Power Apps is powerful when analytics helps the user act. It becomes fragile when you expect a dashboard control to behave like a bidirectional application framework without choosing the right integration pattern.