Fix “Couldn't Load the Model Schema”& “Can't Load This Report” in Power BI Apps
Your viewer can open your Power BI App and see the report title in the left navigation, but every visual breaks with a modal dialog reading: “Couldn't load the model schema associated with this report. Make sure you have a connection to the server, and try again.”
TL;DR Root Cause
The viewer has permission to the Report shell, but is being denied access to the underlying Semantic Model. In a classic Workspace App, cross-workspace semantic models require explicit access in the model's workspace. In both Workspace Apps and Fabric Org Apps, the error also triggers when Row-Level Security (RLS) is enabled on the model and the viewer is not assigned to an RLS role.
Couldn't load the model schema
Couldn't load the model schema associated with this report. Make sure you have a connection to the server, and try again.
Or: “Can't load this report - Couldn't load the schema for the database model”
Why the Server Connection Message Is Misleading
When Power BI displays “Couldn't load the model schema associated with this report. Make sure you have a connection to the server, and try again,”there is rarely anything wrong with Microsoft's servers or your user's internet connection.
In Power BI's architecture, a Report (visual layout) and a Semantic Model(formerly called a Dataset) are two separate security objects. When a viewer opens a report, Power BI first checks if they can view the report shell, and then opens a live Analysis Services query session against the semantic model. If the semantic model rejects that user's identity, Power BI throws the generic model schema error.
Cause 1: Cross-Workspace Semantic Models in Workspace Apps
Many BI teams store shared Semantic Models in Workspace A (Data Hub) and build thin Reports + a Workspace App in Workspace B (Departmental Reporting).
When you publish a classic Power BI Workspace App in Workspace B and add a security group to the App's Audience tab, Power BI only grants permission to items stored inside Workspace B. Per Microsoft's Workspace App documentation, if a report uses a semantic model from another workspace, it is your responsibility to ensure app users have access to that underlying semantic model.
How to Fix Cross-Workspace Model Access for Workspace Apps:
- 1. Open the source workspace (Workspace A) where the shared Semantic Model resides.
- 2. Grant access to the model or workspace: Microsoft's Workspace App publishing guide notes providing Build permission on the underlying semantic model or adding the users to the Viewer role in the semantic model's workspace (or granting access via More options (...) → Manage permissions on the semantic model in Workspace A).
- 3. Use the same security group:Assign the exact Microsoft Entra security group used in Workspace B's App Audience so permissions stay in sync.
Cause 2: Row-Level Security (RLS) Role Assignment in the Model's Workspace
Why does the report load fine for you and your fellow developers, yet immediately fails with “Couldn't load the model schema” or “Can't display the visual” for business viewers?
Per Microsoft's Row-Level Security documentation, the workspace role that determines whether RLS is enforced is the user's role in the workspace where the semantic model is stored. Users with Admin, Member, or Contributor rights in the semantic model's workspace bypass RLS. However, anyone with the Viewer role in the model's workspace (or Read/App access without a higher workspace role on the model) is evaluated by RLS. If the semantic model has any RLS roles defined, those viewers must be assigned to at least one RLS role in the Power BI Service.
How to Assign Viewers to an RLS Role in Power BI Service:
- Go to the workspace containing the Semantic Model, click the three dots (...) on the model, and choose Security.
- Select the appropriate RLS Role on the left, add your viewers' Security Group or email addresses, and click Save.
Cause 3: How Workspace Apps Differ From Fabric Org Apps (GA)
It is important to distinguish between classic Workspace Apps and Microsoft Fabric Org Apps (Organizational Apps), which are now generally available:
Classic Power BI Workspace Apps
Only grant access to items inside the same workspace. If a report connects to a semantic model in another workspace, you must grant access to that model separately in the model's workspace.
Microsoft Fabric Org Apps (GA)
Designed to propagate Read access automatically to supported underlying semantic models for reports included in the Org App, even across workspaces. If an Org App viewer still gets a model schema error, check RLS role membership (Cause 2), DirectQuery / Live Connection gateway access (Cause 4), or grant explicit Read access via Manage permissions on the semantic model (a workaround frequently reported in Microsoft Fabric Community threads when automatic propagation fails).
Cause 4: Live Connection to Analysis Services or DirectQuery With SSO Enabled
If your report uses a Live Connection to Azure Analysis Services (AAS), SQL Server Analysis Services (SSAS), or DirectQuery with Single Sign-On (SSO) through an On-Premises Data Gateway, Power BI passes the viewing user's identity all the way down to SQL/SSAS. If that user (or external B2B guest) does not exist in the on-premises Active Directory or SQL role, the gateway rejects the connection and Power BI surfaces “Couldn't load the model schema.”
Combine Reports From Any Workspace Into One Sidebar Menu
A common reason teams split semantic models and thin reports across dozens of workspaces (and hit cross-workspace Workspace App permission issues) is Power BI's classic 1-Workspace-App-per-Workspace limit. With LumioBI, you can keep reports in the same workspace as their semantic model and still give every department a curated, cross-workspace navigation sidebar directly inside app.powerbi.com via the LumioBI Chrome Extension.
Keep Models & Reports Together
No need to create duplicate thin-report workspaces just to build different department portals.
Cross-Workspace Menus
Combine Finance, Operations, and Executive reports from 10+ workspaces into one unified sidebar.
100% Native RLS
Viewers authenticate with their own Microsoft identity, enforcing all your Power BI security and RLS rules.
Frequently Asked Questions
Why does Power BI say "Couldn't load the model schema associated with this report" for App viewers when the report works for me?
If you have an Admin, Member, or Contributor role in the workspace where the semantic model resides, you automatically bypass Row-Level Security (RLS) and have direct access to the model. Viewers opening the report through a Power BI App only have Read access to the report shell unless they also have permission on the underlying semantic model and are assigned to an RLS role if RLS is enabled on that model.
Does publishing a Power BI App automatically grant access to a semantic model in another workspace?
It depends on which App type you use. In a classic Power BI Workspace App, adding users to Workspace B's App Audience does NOT automatically grant access to a semantic model stored in Workspace A; Microsoft's Workspace App documentation notes you must grant access to the underlying model in Workspace A (such as granting Build permission on the model, adding users to the Viewer role in Workspace A, or granting model permissions). By contrast, Microsoft Fabric Org Apps (now generally available) normally propagate Read access to supported report semantic models automatically, even across workspaces.
Which workspace role determines whether Row-Level Security (RLS) applies to a viewer?
The role that matters for RLS evaluation is the user's role in the workspace where the semantic model is stored, not just the report's workspace. Anyone with Admin, Member, or Contributor access in the semantic model's workspace bypasses RLS, whereas users with the Viewer role in the model's workspace (or Read-only access via an App) must be assigned to at least one RLS role in the semantic model's Security settings when RLS is defined.
When can a Microsoft Fabric Org App viewer still hit 'Couldn't load the model schema'?
Although Fabric Org Apps are generally available and designed to propagate Read access to supported report semantic models across workspaces, viewers can still hit model schema errors if Row-Level Security (RLS) is configured on the model and the viewer is not in an RLS role, if the report uses a Live Connection or DirectQuery source with SSO where the viewer lacks backend permissions, or in community-reported cases where workspace/Org App viewers require explicit Read access via Manage permissions on the semantic model.
Related Power BI Troubleshooting Guides
Power BI Workspace vs. App vs. Org Apps: Why Native Apps Fail Across Multiple Workspaces
Workspaces are built for creators. Power BI Apps and Fabric Org Apps are meant for end users, but break down as soon as viewers need reports from multiple workspaces. See where each falls short and how LumioBI unifies them.
Read guideFix "This Content Isn't Available. Learn More About Power BI" (Embed & App Links)
Why Power BI shows "This content isn't available. Learn more about Power BI" on /reportEmbed iframes, App Content Area links, and B2B guest links, why guests should open direct host-tenant (?ctid=) links, and how LumioBI avoids iframe breaks.
Read guideFix "Sorry, We Couldn't Find That App" or Report in Power BI
Why Power BI shows "Sorry, we couldn't find that app" or "Sorry, we couldn't find that report. It may have been deleted or you may not have access to view it" for external B2B guests and internal viewers, and how to fix tenant and App URL mismatches.
Read guidePower BI Report Not Showing in App: 4 Hidden Causes & Fixes
Added a report to a Power BI workspace but viewers cannot see it in the App? See how un-updated apps, hidden Audience eye icons, and the 1-app-per-workspace limit hide reports, and how LumioBI simplifies publishing.
Read guide