> ## Documentation Index
> Fetch the complete documentation index at: https://docs.langdock.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshoot Power BI

> Fix Power BI errors in Langdock: failing queries, missing Build permission, row-level security errors, delayed permission changes, XMLA and capacity errors, and query limits.

Most fixes need a Power BI admin or the semantic model owner. If you're a business user, share the matching entry with them.

> [accordion] Every query fails, even for users with full access
>
> Enable **Semantic Model Execute Queries REST API** in **Tenant settings** → **Integration settings**. Microsoft's REST documentation calls it Dataset Execute Queries REST API. If the setting is scoped to a security group, confirm the user is in it. Every tier needs this setting, including Fabric capacity.
>
> Also confirm the tenant-wide [admin consent](https://docs.langdock.com/en/admin/manage-integrations/integration-setup-guides/microsoft.md) for Langdock. If your Langdock workspace enabled more Power BI actions after the user connected, the user reconnects once to grant the new permissions.

> [accordion] The workspace or semantic model isn't listed
>
> Langdock only finds items the signed-in Microsoft account can see. Give the user workspace **Viewer** or higher. Models in someone's **My Workspace** are visible only to that person, and you can't grant groups access to it, so move them to a shared workspace.

> [accordion] Queries fail with "the dataset was not found or you do not have the required permissions"
>
> This 404 error means the user has workspace access but no **Build** on the semantic model. Listing reports and models still works, so the connection looks healthy, but **Execute query**, **Get table sample**, **Get table count**, and schema actions fail.
>
> Grant Build on the model, ideally to the user's security group. The change can take about an hour to apply. See [Viewer with Build, or Viewer only](https://docs.langdock.com/en/admin/manage-integrations/integration-setup-guides/microsoft-powerbi/permissions-and-scale.md#viewer-with-build-or-viewer-only).

> [accordion] A query fails on a model with row-level security
>
> If the model has row-level security and the user isn't in any security role, Power BI rejects the query instead of returning empty results. Langdock currently shows a generic `Query execution failed (401)` error, which can look like a broken connection.
>
> Ask the model owner to add the user, or one of their groups, to the right role. Then wait for the change to apply, as described in the next entry.

> [accordion] A permission or role change has no effect yet
>
> Power BI keeps applying a user's previous rights until their access token renews, which can take about an hour. This applies to workspace access, Build, and RLS role changes. While a change applies, some actions can succeed while others already fail. Pausing and resuming the capacity doesn't help.
>
> Wait, or ask the user to reconnect their Microsoft account in Langdock, before you test again.

> [accordion] Some users see more data than expected
>
> If the model uses row-level security, workspace **Contributor**, **Member**, and **Admin**, and **Write** on the model, bypass it. Give consumers workspace **Viewer** plus **Build** instead. See [Workspace roles and row-level security](https://docs.langdock.com/en/admin/manage-integrations/integration-setup-guides/microsoft-powerbi/permissions-and-scale.md#workspace-roles-and-row-level-security).
>
> If every user of a shared agent sees the same data, the agent uses a preselected connection and runs as its owner. Switch the Power BI actions to let each user connect their own account. See [Shared agents and workflows](https://docs.langdock.com/en/admin/manage-integrations/integration-setup-guides/microsoft-powerbi/permissions-and-scale.md#shared-agents-and-workflows).

> [accordion] Some users see different rows than others
>
> If the model uses row-level security, that's RLS working as intended. To check a specific case, run the same query in Power BI as that user and review the Microsoft Entra group membership behind the security roles.

> [accordion] A request fails with "not on dedicated capacity"
>
> Pro workspaces have no XMLA endpoint. Standard DAX queries and schema, measures, and relationships of standard models still work there. This error appears on Pro when the query is a DMV (`$SYSTEM.*`), MDX, or `INFO.*` query other than `INFO.VIEW.*`. Ask a standard DAX question instead, or move the model to a workspace with XMLA. See [What needs XMLA](https://docs.langdock.com/en/admin/manage-integrations/integration-setup-guides/microsoft-powerbi/permissions-and-scale.md#what-needs-xmla).
>
> If the model is a live connection to Analysis Services, see the next entry instead.
>
> On a workspace with capacity, check in this order:
>
> 1. Tenant setting **Allow XMLA endpoints and Analyze in Excel with on-premises semantic models** is enabled, and the user is in its security group if it's scoped.
> 2. The capacity's **XMLA Endpoint** is **Read Only** or **Read Write**, not **Off**.
> 3. The workspace is assigned to that capacity, and the capacity is running. On Premium Per User, the user has a PPU license.
> 4. The user has **Build** on the semantic model.

> [accordion] Every query fails on a model that's a live connection to Analysis Services
>
> Langdock can't query semantic models that are live connections to Azure Analysis Services or SQL Server Analysis Services. Microsoft supports neither the query API nor XMLA for them. On Pro, the error says XMLA isn't available. On capacity, it says the database doesn't exist or you don't have permission to access it. Moving the model to a capacity workspace or changing permissions doesn't help.
>
> To use the data in Langdock, host the model in Power BI or Fabric instead. See [Live connections to Analysis Services](https://docs.langdock.com/en/admin/manage-integrations/integration-setup-guides/microsoft-powerbi/permissions-and-scale.md#live-connections-to-analysis-services).

> [accordion] Measure formulas are empty
>
> Power BI returns measure formulas only over XMLA, and only to users with write permission on the model. Viewers with Build get measure names and descriptions. On Pro workspaces, nobody gets formulas through Langdock. See [What needs XMLA](https://docs.langdock.com/en/admin/manage-integrations/integration-setup-guides/microsoft-powerbi/permissions-and-scale.md#what-needs-xmla).

> [accordion] Schema or measures fail on a Premium Per User workspace and ask you to reconnect
>
> XMLA on a Premium Per User workspace only works for users with a PPU license. For a Pro user, **Get dataset schema**, **Get semantic model measures**, and other XMLA-backed actions fail. Langdock currently reports an invalid or expired access token and asks you to reconnect. The original error at the end of the message is `PowerBINotLicensedException`, and reconnecting doesn't help.
>
> Querying, table samples, and listing still work for that user. Give builders who need XMLA a PPU license, or use a workspace on Fabric capacity.

> [accordion] Report export fails
>
> **Export report to file** fails on Pro and on Premium Per User. The report needs a workspace on Fabric, Power BI Premium, or Embedded capacity.
>
> **Export paginated report** fails on Pro. It runs on Premium Per User, limited to one request per user every five minutes, and on Fabric, Power BI Premium, or Embedded capacity. A paginated report already on Premium Per User doesn't have to move to a capacity workspace.
>
> Ask a question about the data instead, or move a report that can't be exported to a capacity workspace.

> [accordion] The Dataset refresh completed trigger fails
>
> Refresh history needs workspace **Contributor** or higher, or ownership of the semantic model. Viewers with Build can't use this trigger.

> [accordion] List dataset tables fails
>
> **List dataset tables (Push API only)** only works for push datasets. For Import, DirectQuery, and Composite models, use **Get dataset schema** or ask Langdock to query the model directly.

> [accordion] A result is too large
>
> Microsoft limits how much data a single query can return. Ask Langdock for a more focused query, for example with filters or aggregation. See Microsoft's [Execute Queries limitations](https://learn.microsoft.com/en-us/rest/api/power-bi/datasets/execute-queries-in-group#limitations).

> [accordion] Queries fail with too many requests
>
> Microsoft limits how many queries each user can send per minute. Wait a minute and retry. Agents and workflows that query in loops can reach this limit.

> [accordion] Capacity is paused or throttled
>
> Resume the capacity, or wait and retry if Fabric is throttling. If it persists, ask the capacity admin to check the [Capacity Metrics app](https://learn.microsoft.com/en-us/fabric/enterprise/metrics-app). Pro workspaces aren't affected.

## Advanced administration

For current permission, license, and XMLA behavior, see Microsoft's documentation:

* [Execute Queries REST API](https://learn.microsoft.com/en-us/rest/api/power-bi/datasets/execute-queries-in-group)
* [Semantic model permissions](https://learn.microsoft.com/en-us/power-bi/connect-data/service-datasets-permissions)
* [Build permission for shared semantic models](https://learn.microsoft.com/en-us/power-bi/connect-data/service-datasets-build-permissions)
* [Row-level security with Power BI](https://learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security)
* [Semantic model connectivity with the XMLA endpoint](https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-connect-tools)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.