Skip to main content
For most customers, use Single sign-on (SSO). Each request then uses the signed-in user’s Fabric identity and permissions.

​
Choose how Fabric accesses data

Choose Single sign-on (SSO) when users should access each source with their own identity. Users need access to the GraphQL API and its underlying sources. Fabric evaluates the source’s permissions and security rules for the signed-in user. Choose Saved credentials when all API users should access the source through one centrally managed identity. Fabric stores this connection, not Langdock. Users still sign in to Langdock with Microsoft OAuth and need access to the GraphQL API, but Fabric evaluates source access as the saved identity. Each GraphQL API uses one connectivity option across all of its sources. Microsoft documents the current requirements in its authentication and permissions summary.

​
Control who can read or change data

Fabric grants query and mutation execution through the same Run Queries and Mutations API permission, also shown as Execute under direct access. Effective access still depends on what the API exposes and which source permissions apply. With SSO, grant users or Microsoft Entra groups only the source access they need. With Saved credentials, apply least privilege to the saved identity instead. For broader rollouts, use separate GraphQL APIs for distinct audiences or use cases and expose only the relevant sources, objects, and operations in each API. Fabric owns the detailed permission model and source-level controls. Follow Microsoft’s current guidance for the Fabric permission model and the relevant source, such as Fabric SQL databases or Warehouses and SQL analytics endpoints.

​
Add mutations safely

Langdock provides separate actions for GraphQL queries and mutations. Queries cannot execute a mutation. Before Langdock executes a mutation, it asks the user for confirmation. Fabric determines which sources and objects can expose mutations. To keep an API read-only for an audience, do not expose mutations in that API or do not grant its source identity write access. See Microsoft’s current supported sources and operations and GraphQL limitations. For controlled business operations, consider exposing a stored procedure that validates its inputs and applies the complete change. Microsoft documents how to use stored procedures with Fabric API for GraphQL.
Expose a stored procedure that can change data as a GraphQL Mutation. Langdock selects its read or write action from the declared GraphQL operation type. A data-changing procedure exposed as a Query would therefore be treated as a read operation.

​
Preserve individual access in shared agents and workflows

For shared agents and workflows that should preserve each user’s Fabric access, select Their own credentials for the Fabric actions. Each user connects their own Microsoft account, and an API using SSO applies that user’s Fabric permissions. A preselected Langdock connection runs the actions as that connection’s owner. An API using Saved credentials always accesses its sources as the saved Fabric identity, regardless of which Langdock connection calls the API.