Skip to main content
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. No service account is needed. The OAuth scopes each action requests are listed in Power BI scopes. 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 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. 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.

​
What each person needs

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. Microsoft 365 E5 and Office 365 E5 include Power BI Pro. See Microsoft’s Fabric 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.

​
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 and 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.

​
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.