Fabric Multi-Workspace Architecture Overview

How the pieces fit together across a Vault → DataMarts → Reporting flow.

1. Workspace Identities (Service Principals)

Each workspace can have a Workspace Identity (a managed service principal tied to that workspace). Use cases:

Vault WS Identity → authenticates the pipeline to DB2 (via on-prem data gateway or VNet gateway) and writes to the Bronze Lakehouse.
DataMarts WS Identity → reads from the Vault Lakehouse shortcut and writes to the Warehouse.
Reporting WS Identity → used by semantic model refresh / DirectLake to read the Warehouse.

Benefit: no personal accounts in production lineage; identities are granted least-privilege access between workspaces.

2. Connections

DB2 Connection → cloud connection object (stored centrally, reusable). Owned by a service account; the Vault Workspace Identity (or a security group) is granted Use on it.
Fabric-to-Fabric access (Lakehouse shortcuts, Warehouse reads) doesn't need explicit connections — it's governed by workspace roles + item permissions.

3. Workspaces & Roles

Each workspace has four roles: Admin / Member / Contributor / Viewer. Assign AD Groups, never individuals:

Workspace	Admin	Member	Contributor	Viewer
Vault	`AD-Fabric-Platform-Admins`	`AD-DataEng-Leads`	`AD-DataEng`	`AD-Auditors`
DataMarts	`AD-Fabric-Platform-Admins`	`AD-Analytics-Leads`	`AD-Analytics-Devs`	—
Reporting	`AD-Fabric-Platform-Admins`	`AD-BI-Leads`	`AD-BI-Devs`	`AD-Report-Consumers` (or none — use app audiences)

4. AD Groups (recommended pattern)

Build-time groups (workspace roles): AD-DataEng, AD-BI-Devs, etc.
Consumption groups (RLS + app audiences): AD-Sales-East, AD-Sales-West, AD-Finance-Execs.
Keep these separate — devs shouldn't inherit consumer data slices, and consumers shouldn't see dev artifacts.

5. Semantic Models & Reports (Reporting WS)

Semantic model lives in Reporting, connects to Warehouse via DirectLake (preferred) or Import.
Reports are built against the semantic model — not the warehouse directly — so RLS is enforced.
Publish to an Org App; assign consumption AD groups as audiences.

6. RLS (Row-Level Security)

Defined in the semantic model (DAX roles), e.g.

[Region] = LOOKUPVALUE(UserRegion[Region], UserRegion[UPN], USERPRINCIPALNAME())

Map each DAX role to an AD group in the workspace/app Manage permissions dialog.

Critical: consumers get only Read on the model + report, never workspace Viewer (which bypasses RLS for some artifacts). With DirectLake, also ensure they have no direct SQL access to the Warehouse — otherwise they bypass RLS entirely.

Quick mental model

Identities move data, AD groups govern who builds vs. who consumes, workspace roles gate the dev surface, and RLS + app audiences gate the data surface.