Embedding Power BI Reports Inside Dynamics 365 When It Keeps Failing

What is the checklist that fixes most failing Power BI embeds in Dynamics 365?

Work through these before touching form XML or rebuilding anything. Each one is quick to check, and together they account for most of the failures we are asked to look at. Setting locations and licence rules move over time, so confirm each against current Microsoft documentation.

• Embedding is allowed for the environment. A system administrator has to enable Power BI visualization embedding for the Dynamics 365 environment. It sits in the environment feature settings in the Power Platform admin center; older guidance points to the Reporting tab of the legacy system settings.
• The report is not in someone's My workspace. Content in a personal workspace is visible only to its owner, so it works for the author and fails for everyone else, and fails for everyone once that person leaves.
• The viewer can open the report in Power BI. They need the Viewer role in the workspace, access through a Power BI app, or the report shared with them.
• The viewer can read the semantic model. If the report uses a shared semantic model in another workspace, the viewer needs read permission on that model as well.
• The viewer has the right licence. On shared capacity, viewers need Power BI Pro, or Premium Per User for content in a Premium Per User workspace. Free viewers only work where the workspace is on a capacity that allows them, and a paused capacity stops everything.
• The user signs in to Power BI with the same organizational account and tenant as Dynamics 365. Guest and cross-tenant cases are covered below.
• Row-level security lets the user see something. A viewer who is not in any role, or whose mapping has no rows, gets an error or an empty report.

What is the difference between a personal dashboard embed, a system dashboard and a report on a form?

They are three different features, and a fix for one does not apply to the others. Start by identifying which one each failing embed is.

What permissions does the viewing user actually need?

Two sets, and the embed only works when both are satisfied. On the Dynamics 365 side, the user needs access to the app, the dashboard or form, and the record the form is showing. On the Power BI side, the embed runs as the signed-in user, not as a service account, so the user needs everything they would need to open the same report directly in Power BI: a suitable licence, access to the report through a workspace role, an app or sharing, and read access to the semantic model.

If the model uses DirectQuery to Dataverse with single sign-on, the user also needs Dataverse access to the underlying rows, and their Dynamics 365 security roles filter what they see. Grant Power BI access through Microsoft Entra security groups that mirror the Dynamics 365 audience, rather than to individuals, so a new starter who gets the Dynamics role also gets the report.

Why do Power BI embeds fail for guest users or across tenants?

Because the embed signs the user in to Power BI in their current identity, and that identity has to be able to reach content in the Power BI tenant where the report lives.

• Report in a different tenant from Dynamics 365. The embed expects the report in the same organization's Power BI. Content published to another company's tenant, such as a partner's or a previous parent company's, will not load; republish it into your own tenant.
• B2B guest users in Dynamics 365. Guest access to Power BI has to be allowed in the Power BI tenant settings, the guest needs access to the workspace or app and a licence that covers them, and conditional access policies must allow guest sign-in.
• Several accounts in one browser. A user signed in with a personal or second work account can be sent to the wrong Power BI identity; test in a private window with only the work account.
• Browser privacy settings. Blocking third-party cookies or sign-in pop-ups can stop the embedded frame authenticating; check against your organization's browser policy.
• Row-level security for guests. The name a guest resolves to may not match the name stored in your mapping table, so test guests explicitly.

In what order should you diagnose a failing Power BI embed?

Go from the user outwards, and change one thing at a time. The mistake that wastes the most time is testing as an administrator: system administrators and workspace Admins, Members and Contributors often have access, and bypass row-level security, that ordinary users do not.

• Reproduce as a non-admin user who actually has the problem, or a test account with the same Dynamics 365 roles, groups and Power BI licence. If it works for you and not for them, the cause is permissions, licence or RLS.
• Open the same report directly in Power BI as that user. If it fails there too, the problem is in Power BI, not Dynamics 365, and no form change will fix it.
• Open the browser developer tools on the failing page. Read the console and the failed network requests to Power BI endpoints: the status and error text usually say whether it is authentication, permission, content not found or capacity.
• A not-found style error usually means a wrong or stale workspace or report id, for example after a report was republished or a solution imported from another environment.
• A permission or unauthorised style error means licence, workspace, app, semantic model or guest access for that user.
• If the report loads but visuals show errors or no data, test the user's row-level security with Test as role in the semantic model security settings, and check they are in a role with mapping rows.
• For form embeds that show the wrong data, check the filter against the model's exact table and column names and the value format of the Dynamics column.

How do you check that row-level security roles resolve for the viewing user?

In the Power BI service, open the semantic model's security settings, confirm the user or a group they belong to is a member of a role, and use Test as role for that person. If the model uses a mapping table keyed on user principal name, check the person has rows in it and that their name matches exactly, including case and any change after a rename.

If the embed only fails for some managers, or shows other people's data, the problem is the security design, not the embed. Building a mapping table, the USERPRINCIPALNAME() rule, manager hierarchies and who bypasses RLS are covered in our guide to Power BI row-level security over Dynamics data without Premium.

How do you stand up twenty Power BI embeds repeatably instead of one at a time?

Treat the embeds as a small product with an inventory, not twenty individual favours. The work is mostly in making every embed follow the same pattern, so that once one works, the rest work for the same reasons.

• Build a register: for each embed, the app, the dashboard or form, the embed type, the workspace, report and semantic model, the audience group, the RLS role, the business owner and the last date it was tested as a non-admin.
• Move every report out of personal workspaces into shared workspaces owned by a group, one per environment where you separate development, test and production.
• Give access through Entra security groups and a Power BI app or the Viewer role, matched to the Dynamics 365 audience in the register.
• Keep Power BI embedded system dashboards in a solution and use environment variables for workspace and report references where supported, so imports into test and production point at the right content. Our Power Platform ALM guide covers moving solutions between environments.
• Replace personal dashboard embeds that a whole team relies on with system dashboards, so they no longer depend on one user.
• Test each embed as a named non-admin user after every deployment and record the result in the register.

What if the technical owner has left and nobody knows how the embeds were set up?

Start from the register above, filled in from what the system shows rather than what anyone remembers: dashboards and forms in the solutions, Power BI workspaces and their owners, and the embed settings. Personal workspaces and personal dashboards belonging to the person who left are the first things to move, before their account is removed and the content goes with it.

If the embeds are one symptom of a wider inherited environment with no documentation, take stock of the whole system first; our guide to taking over an undocumented Dynamics 365 environment sets out that sequence, and our Dynamics 365 health check is the independent review that produces a prioritized list before an audit. Why reports belong inside the app at all, and the model under them, is covered in our Power BI for manufacturing guide.

Is embedded Power BI the right reporting approach, or does the platform need rethinking?

Usually it is right. Reports inside the forms and dashboards people already use get read, and once permissions follow groups and embeds follow one pattern, they are stable. What a Dynamics 365 engagement covers is on our Dynamics 365 consulting page.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. If per-user Power BI and Dynamics 365 licensing across a large audience is the real problem behind the failures, a custom-built CRM on React, Node.js, PostgreSQL or .NET can carry its reporting built in, without Microsoft licensing.

How does Solzet fix failing Power BI embeds in Dynamics 365?

We build the register from the live system, reproduce each failure as a non-admin user, classify the cause from the checklist and the console errors, fix settings, workspaces, group access, semantic model permissions and row-level security, and move embeds into a repeatable solution-based pattern. You get every embed working for its audience, the register with test results, and a short note on how to add the next one.

The work is done by senior consultants and full-stack developers delivering remotely from Yerevan, Armenia, with 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly for your team or white-label for Microsoft partners.