Access and Roles¶
Access to the platform runs through Entra ID groups. Individual users are not assigned roles in the configuration.
Workspace roles are Fabric roles (managed through the fabric_workspace_role_assignment resource), not Azure RBAC roles.
Workspace roles¶
Each workspace can have a group for each of four roles. All four are optional in the configuration.
| Role | What it allows |
|---|---|
| Admin | Full control of the workspace: manage settings, add and remove users and groups, configure workspace-level features. Does not override the access of the deploying service principal. |
| Contributor | Create, edit and delete items in the workspace. Gets usage rights on the connections of the workspace (see below). |
| Member | Extended rights, including management of workspace settings. |
| Viewer | Read-only access to workspace items. |
The groups are given as Object ID or as display name. The ID takes priority if both are set. The display name is resolved at plan time.
One role per group
Fabric enforces one role per principal per workspace. Use a different group for each role. The configuration contains a check that reports the same group in two roles, and Fabric rejects it at apply time.
The optional Admin group¶
The Admin role lets your team manage workspace settings and users without raising a ticket for each change. Configure it with
admins_group_id on each workspace.
What a workspace admin can do:
- add and remove users and groups for Contributor, Member and Viewer,
- manage workspace settings (description, sensitivity labels, endorsement),
- configure workspace-level features (lineage, Git integration settings),
- delete workspace items and manage access requests.
What a workspace admin cannot do:
- change the capacity of the workspace (platform-managed),
- change the network policies (platform-managed through Terraform),
- remove the access of the deploying service principal, which keeps implicit admin rights as the creator of the workspace.
What you provide¶
| Item | Who | Notes |
|---|---|---|
| Entra ID security group per environment boundary | Workload team or your identity team | For example one for production and pre-production workspaces and one for development workspaces |
| Object ID of each group | Workload team, to the platform team | |
| Group membership | Workload team | You add your own people |
The platform team adds the Object ID to the workspace configuration and deploys. The plan then shows only additive changes (a new role assignment). Workspaces are not recreated and nothing is disrupted. To roll back, remove the group from the configuration: the next deployment removes the assignment.
Drift and manual role assignments¶
Terraform manages only the assignments it creates.
- If a workspace admin adds more assignments in the Fabric portal, Terraform does not detect or revert them. The platform manages the baseline, the workload team manages the extras.
- If someone removes an assignment that Terraform manages, the next deployment recreates it.
Troubleshooting¶
| Symptom | Cause | Resolution |
|---|---|---|
409 Conflict during deployment |
The group was already assigned manually as Admin in the Fabric portal | The platform team adds a temporary Terraform import block for the assignment (ID: <workspace id>/<principal id>), deploys once and removes the block again. Or remove the manual assignment first. |
Warning from the unique_role_groups check |
The same group is used for two roles | Use distinct groups, or remove the duplicate |
| The admin group cannot see the workspace | Wrong object ID, or the group has no members | Check the ID in Entra ID and make sure the group has at least one member |
Connection usage rights¶
The connections that the platform creates are shared with groups through the connection role User:
| Connection | Groups that get the User role in the code |
|---|---|
| ADLS, SQL (both authentication types), Oracle Cloud Storage | The Contributor group of the workspace |
| GitHub connection of a workspace with a Git link | The Contributor group and the Member group of the workspace |
The service description says that Contributors and Members get usage rights on workspace connections. Check with your platform team which groups are applied in your deployment.
Capacity roles¶
| Role | Where | Who |
|---|---|---|
| Capacity administrator | On the Fabric capacity | Service principals of the spokes that deploy to the capacity, and optionally individual users. Groups cannot hold this role. |
| Fabric Capacity Operator (custom Azure role) | On the shared resource group | The pause and resume Logic Apps, and the Entra ID groups that may pause and resume manually. See Cost optimisation. |
Other access¶
| Resource | Access model |
|---|---|
| Managed Grafana | Three dedicated Entra ID groups for Admin, Editor and Viewer. They are separate from the Fabric workspace groups: access to Grafana is not access to Fabric. See Monitoring. |
| Microsoft Purview | The deploying principal has Contributor on the account, an optional data team group has Reader. See Governance. |
| Data lake storage | OAuth only. The service principal that deploys has Storage Blob Data Contributor. |
| Key Vault | Connection secrets are read by the deployment identity when the pipeline runs. |
Access requests follow the normal change process: Request and change. General rules for groups and just-in-time access on the platform are in Access, groups and PIM.