IT Admin Data Architect Platform Owner — This section covers data governance frameworks, Microsoft Purview integration, security models, workspace roles, RLS/CLS, and network security in Fabric.
Governance
Establishing data governance, cataloging, quality, and trust across your Fabric environment.
Governance Framework
Effective governance in Fabric combines Microsoft Purview for cataloging and lineage, endorsement for trust signals, sensitivity labels for data protection, and organizational policies for access control.
Microsoft Purview Integration
Fabric integrates deeply with Microsoft Purview for enterprise-wide data cataloging, lineage, and compliance. For a comprehensive guide covering OneLake Catalog, Purview capabilities, and how they work together, see the dedicated Catalog & Governance page.
- Data Catalog: Automatically discovers and catalogs all Fabric artifacts (lakehouses, warehouses, reports)
- Data Lineage: Visual, end-to-end lineage from source ingestion through transformation to Power BI reports
- Data Map: Browse and search across your entire data estate
- Glossary: Define business terms and link them to technical assets
Data Domains & Ownership
Organize your Fabric workspaces into logical domains (e.g., Finance, HR, Marketing) to align with business ownership.
- Assign a domain owner responsible for data quality and access within their domain
- Use Fabric domains feature to tag workspaces by business area
- Establish a data stewardship model — stewards per domain for hands-on governance
Endorsement
Fabric provides two endorsement levels to signal trust in artifacts:
Promoted
Workspace members can promote artifacts to indicate they're ready for broader use. A lightweight signal that says "this is reliable."
Certified
Only designated reviewers can certify artifacts. This is the highest trust level — it means the artifact meets organizational quality and governance standards.
Establish a certification process: define criteria (documentation, testing, data quality checks) that an artifact must pass before being certified. Only Gold-layer datasets and production reports should be certified.
Sensitivity Labels
Microsoft Information Protection (MIP) sensitivity labels can be applied to Fabric artifacts to classify and protect data:
- Labels flow downstream automatically — if a lakehouse is labeled "Confidential," reports built on it inherit the label
- Labels can enforce encryption and access restrictions on exported data
- Integrates with Microsoft 365 compliance center and DLP policies
Data Quality
- Implement data quality rules in notebooks (Great Expectations, custom Spark checks)
- Use Delta Lake constraints (NOT NULL, CHECK) for schema-level enforcement
- Set up monitoring and alerting for data freshness, completeness, and accuracy
- Create a data quality dashboard in Power BI for visibility
Security
Securing your data at every layer — from identity and workspace access to row-level permissions and network controls.
Fabric implements a defense-in-depth approach with multiple security layers. For a comprehensive walkthrough of every layer, see the dedicated Security page.
🔐 Identity & Access
Entra ID, Conditional Access, MFA, service principals, workspace identity
🛡️ Data Security
RLS, CLS, OLS, Dynamic Data Masking, OneLake folder-level RBAC
🏷️ Information Protection
Sensitivity labels, DLP policies, Copilot AI data boundaries
📊 Monitoring
Audit logs, Defender for Cloud Apps, Sentinel integration
Explore the full layered security model with interactive diagrams, code examples, decision matrices, and a hardening checklist → Security Deep Dive →
Governance-First Assessment
Assess your organization's governance maturity across domains, development process, security, and workspace design — then get tailored recommendations grounded in Microsoft's official best practices.
Answer 12 questions across 4 categories. You'll receive a governance maturity score with per-category breakdowns and actionable recommendations for building a governance-first Fabric environment.
1. How are business domains defined in your organization?
2. Do domain owners have accountability for data quality and access?
3. How do teams discover and request access to data from other domains?
4. How do you manage changes to Fabric artifacts (notebooks, pipelines, reports)?
5. Do you have separate environments (Dev / Test / Prod)?
6. How are deployments promoted across environments?
7. How are workspace roles assigned?
8. Do you enforce data-level security (RLS, CLS, OneLake roles)?
9. Are sensitivity labels and conditional access configured?
10. How is your workspace structure organized?
11. How do you manage capacity assignment for workspaces?
12. Do you use Fabric domains to logically group workspaces?
Building a Governance-First Fabric Environment
A practical blueprint for designing your Fabric estate with governance, security, and access control from day one — based on official Microsoft best practices.
Don't retrofit governance after deployment. Design your Fabric environment with domains, security, workspace structure, and development lifecycle defined upfront. This avoids the costly cycle of organic sprawl → audit failures → forced refactoring.
🏛️ Domain Strategy & Ownership
Organize your Fabric estate around business domains — not technical teams or projects. Each domain should have clear ownership and delegated governance authority.
Define Domains & Subdomains
Map domains to major business units (Finance, Sales, HR, Marketing). Use subdomains to keep categories manageable (e.g., Sales → Domestic, International). Assign a domain admin with delegated control over domain policies.
Data Stewardship Model
Appoint data stewards per domain responsible for quality, access requests, and metadata curation. Stewards work with the domain admin but focus on hands-on data governance — ensuring datasets are documented, endorsed, and accurate.
Data Discovery via Purview
Enable Microsoft Purview for cataloging, lineage, and glossary. Use endorsement (Promoted / Certified) to signal trust. Data consumers should be able to discover, evaluate, and request access to datasets through the catalog — not ad-hoc emails.
📐 Workspace Topology
Workspaces are both a security boundary and an operational boundary in Fabric. Design them intentionally before creating any content.
Environment Separation
Create Dev / Test / Prod workspaces per domain or data product. Example: Finance-Dev, Finance-Test, Finance-Prod. Never develop directly in production workspaces.
Naming Conventions
Enforce a consistent naming standard: [Domain]-[Product]-[Env]. Examples: Sales-Analytics-Prod, HR-DataLake-Dev. This enables at-a-glance identification and automated governance policies.
Capacity Assignment
Assign workspaces to capacities based on criticality. Production workloads on Fabric/Premium capacities for SLA guarantees. Development/test on smaller or trial capacities. Monitor utilization via the admin monitoring workspace.
🔐 Security Layering
Fabric implements defense-in-depth with five security layers. A governance-first environment configures all layers before exposing data to users.
| Layer | Mechanism | Governance-First Action |
|---|---|---|
| 1. Identity | Entra ID, Conditional Access | Enforce MFA, restrict access by location/device via conditional access policies |
| 2. Workspace | Workspace Roles (Admin/Member/Contributor/Viewer) | Assign via Entra ID security groups, default to Viewer, elevate only with justification |
| 3. Item | Item-level permissions, sharing | Grant per-item read/reshare only for cross-domain sharing scenarios |
| 4. Data | RLS, CLS, OneLake data access roles, dynamic data masking | Configure OneLake folder-level roles for lakehouse data; layer RLS/CLS on warehouses and semantic models; mask PII columns |
| 5. Network | Private endpoints, managed VNets, trusted workspace access | Enable private endpoints for sensitive workloads; use managed VNets for Spark outbound traffic control |
□ Enable Entra Conditional Access | □ Create security groups per workspace role | □ Configure OneLake data access roles | □ Apply sensitivity labels with auto-labeling | □ Enable audit logs | □ Set up quarterly access reviews
📚 Official Docs
Security Overview ↗ OneLake Data Access Roles ↗ Permission Model ↗ Secure Your Data ↗🚀 Development Lifecycle
A governed development lifecycle ensures changes are tracked, reviewed, tested, and promoted safely — not edited directly in production.
Git Integration
Connect all workspaces to Azure DevOps or GitHub repositories. Use branch policies requiring pull requests and at least one reviewer. Map branches to environments: feature/* → Dev, main → Prod.
Deployment Pipelines
Use Fabric's native deployment pipelines to promote artifacts across Dev → Test → Prod stages. Configure approval gates so production deployments require sign-off from domain owners or data stewards.
Environment Configuration
Use variable libraries to manage environment-specific settings (connection strings, capacity, parameters) without manual changes. Automate deployment orchestration via GitHub Actions or Azure Pipelines.
Microsoft offers two CI/CD patterns: Git-centric (each environment maps to a branch; deploy by merging) and Pipeline-centric (single branch linked to Dev; deploy via Fabric deployment pipelines). Choose based on your team's maturity. Pipeline-centric is simpler to start; Git-centric offers more flexibility for large teams.