A visual guide to the 7 governance domains — from tenant settings to deployment pipelines.
The foundation of your Fabric environment. Tenant settings control who can do what across the entire organization — from workspace creation to external sharing to AI features.
Fabric ships with permissive defaults. If you don't review them, every user can create workspaces, share externally, and use AI features without guardrails.
Too many Fabric Admins means too many people can change tenant-wide settings. Limit admin roles and use PIM for just-in-time access.
The default 90-day retention means you lose compliance evidence. Export to Log Analytics or a storage account for long-term retention.
Microsoft releases new features monthly. Without a review process, new toggles get enabled without evaluation — creating shadow governance gaps.
Export a baseline of all tenant settings before making changes.
This becomes your audit trail and rollback reference.
Use security groups to scope tenant settings.
Instead of enabling a feature for the entire org, enable it for a pilot group first.
At maturity, manage tenant settings via Infrastructure-as-Code.
Changes go through pull requests with approval, not manual portal clicks.
Copilot and AI features consume capacity units and can expose data.
Define who can use them, in which workspaces, and monitor CU impact.
Workspaces are the organizational unit of Fabric. How you structure them determines your security boundaries, collaboration patterns, and ability to scale.
Without governance, teams create workspaces ad-hoc. Within months you have hundreds of 'Test', 'Copy of', and abandoned workspaces nobody owns.
Without a naming standard, you can't tell what a workspace contains, who owns it, or what environment it belongs to.
Putting everything in one workspace means everyone has access to everything. No separation between raw data, curated models, and consumer reports.
Without endorsement governance, users don't know which models are trusted. They build reports on draft or experimental data.
Pattern A (Recommended): One workspace per data product — great for data mesh.
Pattern B: Per medallion layer — for strict regulatory needs.
Pattern C: Consolidated — only for small pilots.
Format: {Domain} - {Layer/Purpose} - {Description} [{Env}]
Example: Finance - Gold - Revenue Reporting [Prod]
Enforce via automation, not email reminders.
Bronze = raw ingestion (land as-is).
Silver = cleansed and conformed.
Gold = curated business models ready for consumption.
Each layer = its own workspace for access control.
Review workspaces quarterly.
Archive unused workspaces after 90 days of inactivity.
Delete after 180 days.
Automate notifications to owners.
Domains enable federated governance — letting business units own their data while the central team sets guardrails. This is how Fabric scales beyond one team.
Creating a domain per team or project leads to fragmentation. Start with 3–7 aligned to major business functions.
A domain without an admin is just a label. Every domain needs a named administrator who is accountable.
If the central team must approve every workspace, every access request, and every deployment, you've created a bottleneck.
Without endorsement and certification, consumers can't distinguish authoritative data from experimental datasets.
Domains should map to business functions (Finance, Sales, Operations) or value streams.
Not to reporting lines — org charts change; business functions are stable.
Fabric Admin → sets tenant-level guardrails.
Domain Admin → manages workspaces, access, and settings within their domain.
Domain Contributor → self-service within boundaries.
Two levels:
Promoted — owner recommends it.
Certified — formally reviewed against quality criteria.
Certification should require documented lineage, refresh reliability, and owner accountability.
Configure a default domain so new workspaces aren't orphaned.
Route them to a 'Sandbox' or 'Unassigned' domain for triage.
Who can see what, who can change what, and how you enforce least privilege. This domain covers workspace roles, row-level security, sensitivity labels, and identity governance.
Making everyone a 'Member' role gives them edit access to all content. Most users should be Viewers.
Assigning access to john@company.com instead of 'Finance-Analysts' security group means no one knows who has access.
Without labels, a confidential financial model looks the same as a public marketing dashboard.
Adding Row-Level Security after go-live means users have already seen data they shouldn't.
Admin — infrastructure changes.
Member — create/edit content.
Contributor — edit only assigned items.
Viewer — read-only.
Map each to a security group.
Four tiers: Public, Internal, Confidential, Highly Confidential.
Enable label inheritance — when a Lakehouse is labeled 'Confidential', downstream reports inherit it.
Use Privileged Identity Management (PIM) for admin roles.
Admins activate their role for a time-limited window, with approval and audit trail.
Static RLS: map security groups to data filters (e.g., region = 'EMEA').
Dynamic RLS: use USERPRINCIPALNAME() for per-user filtering.
Always test with 'View as Role'.
Fabric uses a capacity-based model where compute is shared across workloads. Understanding CU consumption, throttling, and cost attribution is essential to avoid surprise bills.
A single capacity means one runaway notebook can throttle everyone's reports. Separate at least by environment.
Fabric smooths CU consumption over 24 hours. Teams misread this as 'unlimited' until they hit rejection.
Without showback, no one knows their workloads cost $8K/month.
Starting with F64 when F8 would suffice wastes thousands per month. Start small, monitor, right-size.
Pattern 1: Single shared (NOT for prod).
Pattern 2 (Recommended): Per domain — enables cost attribution.
Pattern 3: Per workload type (interactive vs background).
Pattern 4: Per environment + domain (enterprise).
Deploy the Capacity Metrics app on day one.
Review weekly. Scale based on data, not guesses.
F2 handles more than you'd expect for BI-only workloads.
Fabric's 24h smoothing window absorbs burst usage.
But if your average exceeds capacity:
1. Background jobs get delayed (10min+)
2. Interactive queries get throttled
3. Everything gets rejected
Start with showback: give each domain visibility into their CU consumption.
After 6–12 months of stable patterns, transition to chargeback for true cost accountability.
Protecting data at rest, in transit, and in use. This covers DLP policies, data classification, lineage, Purview integration, network security, and regulatory compliance.
Many orgs enable DLP in 'monitor mode' and never transition to enforcement. Set a deadline (4–6 weeks) to move to blocking.
Without classification, you can't apply the right protection. A 'Highly Confidential' dataset and a public reference table get the same (lack of) protection.
If data flows through external tools (ADF, Databricks) before landing in Fabric, built-in lineage breaks.
Shortcuts let any workspace reference data from another. Without governance, you create invisible data dependencies.
Apply sensitivity labels when data enters Fabric (Bronze layer).
Labels flow downstream through lineage.
Don't wait until the Gold layer — by then, unclassified data has already been exposed.
Week 1–2: Test mode (no user impact).
Week 3–4: Monitor mode (log violations).
Week 5+: Enforce with policy tips (block + educate).
Review false positives weekly.
Fabric has built-in lineage, but Purview extends governance across Azure SQL, Databricks, Power BI, and external sources.
Register Fabric as a Purview source for unified catalog.
Tier 1: Public endpoints (default — fine for non-sensitive data).
Tier 2: Conditional Access policies (restrict by location/device).
Tier 3: Private Link + Managed VNet (for regulated industries).
Operational excellence: how you deploy changes, monitor health, and ensure reliability. Covers Git integration, CI/CD, the Capacity Metrics app, and change management.
Editing directly in the Fabric portal means no history, no rollback, no code review.
Copy-pasting between Dev and Prod introduces human error. Missed configurations, wrong connection strings.
The Capacity Metrics app is free and gives you CU consumption, throttling events, and refresh success rates.
Code gets unit tests; data gets nothing. Without data validation, bad data silently flows to production.
Fabric's built-in Deployment Pipelines are the easiest way to promote content.
Dev → Test → Prod with no code required.
Great for BI teams getting started.
For engineering teams, the fabric-cicd Python library enables code-first deployments.
Use parameter.yml for environment configs.
Use lakehouse_id.yml for target mapping.
Connect workspaces to Azure DevOps or GitHub.
Use feature branches for development, PRs for review, and main branch for production.
Sync is automatic.
Deploy Capacity Metrics app. Set alerts for:
CU utilization > 80%
Refresh failure rate > 5%
Query duration > SLA threshold
Review weekly — don't wait for user complaints.