> ## 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. # Control Power BI access at scale > Choose Power BI licenses and roles for Langdock, understand how row-level security and XMLA affect each action, and roll out to many users. > [!TIP] > > Give the people who use Langdock **Viewer** on the workspace and **Build** on the semantic model. A Power BI Pro license is enough. They don't need Fabric capacity, XMLA, or any capacity role. Langdock uses delegated Microsoft permissions. Each request runs as the signed-in user, so Langdock can't read a model the user can't already access, and any row-level security (RLS) on the model filters for that person. The exception is a shared agent or workflow that uses a preselected connection. See [Shared agents and workflows](#shared-agents-and-workflows). No service account is needed. The OAuth scopes each action requests are listed in [Power BI scopes](https://docs.langdock.com/en/admin/manage-integrations/microsoft-integration-scopes/power-bi.md). ## Recommended setup Put the business context into the semantic model itself. Then any Langdock user with access can ask questions in plain language without extra setup, and the context stays in the one place your data team already maintains. * Give tables, columns, and measures clear business names, for example `Net Revenue` instead of `NR_AMT`. Names matter most, because Langdock sees them in every lookup. * Add a one-line description to each key measure, for example "Revenue from won opportunities, excluding returns". * Group measures in display folders, add synonyms in the linguistic schema, and hide technical columns such as keys and sort helpers. If users still need guidance the model can't hold, such as business rules, which measure to prefer, or how to present answers, write a [Skill](https://docs.langdock.com/en/using-langdock/skills/skills-integrations.md) with the Power BI integration attached and share it with them. A Skill works in regular chats, so users don't have to find a separate agent. It always uses each user's own Power BI connection, so their own permissions apply. In the Skill, refer to measures by name, not by how they're calculated. ## Viewer with Build, or Viewer only Only Viewer with Build lets Langdock answer questions with data. | Capability | Viewer with Build | Viewer only | | - | - | - | | List and search workspaces, reports, semantic models, and dashboards | Yes | Yes | | Answer with numbers and browse tables, columns, measures, and relationships | Yes | No | Microsoft requires Build for the query API that every data action uses. Without it, Langdock can help users find the right report but returns no data. Withholding Build doesn't make access safer. If different users should see different rows, use [row-level security](#workspace-roles-and-row-level-security). ## What each person needs | Person | Grant | Don't grant | | - | - | - | | Consumer, who asks questions | Workspace **Viewer**, **Build** on the semantic model, Power BI Pro | Contributor or higher, **Write** on the model, or any capacity role | | Builder, who prepares the model and any Skill | Consumer access to production. For measure formulas in Langdock, Contributor or higher on a model copy on Fabric capacity or Premium Per User | Contributor or higher on production models they don't own | | Workspace or BI owner | Workspace Admin or Member to publish models and grant Build | Capacity roles, unless they also run the capacity | | Capacity admin, only for XMLA | Capacity Admin on the Fabric or Power BI Premium capacity | Data access through this role | Asking questions only needs read access, so consumers don't need Contributor or higher. Builders need write access only to see measure formulas, because formulas need both XMLA and write permission on the model. That's why write access goes on a copy they own. Contributor and higher let people change or delete the shared model, and if the model uses RLS, they also bypass it. ## Licenses Querying works the same on every tier. Tiers differ in who can use the content and whether the XMLA endpoint is available. | Tier | Who can use the content | XMLA | What it means for Langdock | | - | - | - | - | | Pro | Pro and PPU users | No | Full querying. The recommended default for consumers | | Premium Per User (PPU) | PPU users in Power BI. Pro users with Viewer and Build can still run queries through Langdock, but schema and measure actions fail for them | Only for PPU users | A low-cost XMLA option for builders | | Fabric F2 to F32 | Pro or PPU users | Yes | Same querying as Pro, plus XMLA. Useful for builders, not needed for consumers | | Fabric F64 and larger, Power BI Premium P1 and larger | Free users with workspace Viewer | Yes | Consumers need no paid license | Microsoft 365 E5 and Office 365 E5 include Power BI Pro. See Microsoft's [Fabric licenses](https://learn.microsoft.com/en-us/fabric/enterprise/licenses). ## Workspace roles and row-level security Keep consumers as **Viewers**. Workspace Admin, Member, and Contributor include write access to every model in the workspace. Grant roles, **Build**, and any RLS roles to Microsoft Entra security groups rather than to individual users, so access follows your existing organization structure. Without RLS, every Viewer with Build sees all data in the model. If a model uses RLS, keep these in mind: * Langdock returns only the rows the user's security role allows. * Write access bypasses RLS, so a workspace-wide Contributor grant turns RLS off for everyone who holds it. * Add the same Entra groups that get Viewer and Build to your security roles, so every consumer lands in a role. Users outside every role get an error, not empty results. ## What needs XMLA Most actions use the Power BI REST APIs and work on every tier. A few need the XMLA endpoint, which requires Fabric capacity, Power BI Premium capacity, or Premium Per User, plus the [XMLA settings](https://docs.langdock.com/en/admin/manage-integrations/integration-setup-guides/microsoft-powerbi/setup.md#optional-enable-xmla-backed-actions). | Action | Works on Pro | | - | - | | **Execute query** and the **Data value changed** trigger | Yes, for DAX. DMV (`$SYSTEM.*`), MDX, and `INFO.*` queries other than `INFO.VIEW.*` need XMLA | | **Get dataset schema**, **Get semantic model measures**, **Get semantic model relationships** | Yes, without measure formulas. Formulas need XMLA and write permission | | **Get table sample**, **Get table count**, and list, search, and details actions | Yes | | **Export report to file** | No. Needs Fabric, Power BI Premium, or Embedded capacity. Premium Per User isn't supported | | **Export paginated report** | No. Runs on Premium Per User, one request per user every five minutes, and on Fabric, Power BI Premium, or Embedded capacity | | **Dataset refresh completed** trigger | Yes, for Contributor or higher, or the model owner | ## Live connections to Analysis Services Langdock can't query semantic models that are live connections to Azure Analysis Services or SQL Server Analysis Services, on any tier. Microsoft supports neither the query API nor the XMLA endpoint for these models, and Fabric capacity doesn't change that. To use the data in Langdock, host the model in Power BI or Fabric instead. Microsoft lists these limits in [Execute Queries](https://learn.microsoft.com/en-us/rest/api/power-bi/datasets/execute-queries-in-group#limitations) and [Unsupported semantic models](https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-connect-tools#unsupported-semantic-models). ## Shared agents and workflows To keep each user's own Power BI access in a shared agent or workflow, select **Yes, users will need to connect their Power BI account** for the Power BI actions. Each user connects their own Microsoft account, and their own permissions apply. With **No, all users should use the same, preselected connection**, every action runs as the connection's owner. Use this only when every caller should see the same data. See [Connections](https://docs.langdock.com/en/using-langdock/integrations/connections.md). ## Admin checklist Check each item where it's listed. The expected state follows the colon. * [ ] Fabric admin portal → **Tenant settings** → **Integration settings** → **Semantic Model Execute Queries REST API**: enabled for the entire organization, or for a security group that contains every Langdock user. * [ ] Each workspace → **Manage access**: the consumer group has the **Viewer** role, not Contributor, Member, or Admin. * [ ] Each semantic model users query in Langdock → **Manage permissions** → **Direct access**: the consumer group shows **Build**, without **Write** or **Reshare**. * [ ] Microsoft 365 admin center → **Billing** → **Licenses**: every consumer has Power BI Pro, Power BI Premium Per User, Microsoft 365 E5, or Office 365 E5. Builders who use XMLA on a Premium Per User workspace have Premium Per User. * [ ] Only if a model uses RLS: semantic model → **More options** → **Security**: every consumer group is a member of at least one role. * [ ] Only if builders need XMLA: Fabric admin portal → **Capacity settings** → the capacity that hosts builder models → **Power BI workloads** → **XMLA Endpoint**: **Read Only** or **Read Write**. * [ ] Only if you share agents or workflows that use Power BI: in Langdock, each of them → each Power BI action: **Yes, users will need to connect their Power BI account** is selected. * [ ] A representative consumer passes [Validate the setup](https://docs.langdock.com/en/admin/manage-integrations/integration-setup-guides/microsoft-powerbi/setup.md#validate-the-setup). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.