Microsoft Fabric: The Complete Platform Reference

This is the complete practitioner reference for Fabric's platform fundamentals — every primitive in depth, plus licensing, networking, Item Recovery, the on-premises gateway, Fabric Apps/Rayfin, and V-Order internals. For the shorter architect's field guide to tenant/workspace structure, OneLake, governance, and capacity isolation as design decisions, see Platform & Governance in Microsoft Fabric.

Microsoft Fabric is a SaaS analytics platform that consolidates the full data lifecycle — ingestion, transformation, stream processing, warehousing, data science, and BI reporting — inside a single product ^[S1]. Rather than assembling a patchwork of independent Azure services, teams work inside one environment where every workload shares the same storage, the same governance layer, and the same embedded AI assistance ^[S1].

The practical implication is significant: a data engineer, an analyst, and a data scientist can all work on the same datasets without handoffs, format conversions, or duplicate copies. The platform is designed so that any output from one workload is immediately consumable by every other, and that promise holds because all of them write to a shared store in a common format ^[S2].

This article is a complete reference for Fabric's platform fundamentals — the concepts, the architecture, the licensing model, the governance layers, networking choices, operational tooling like Item Recovery and the on-premises data gateway, the emerging Fabric Apps surface, and the internal optimization that makes cross-engine reads fast. It is grounded in verified claims only; anything beyond those claims is labeled Inference:.

What Fabric Is (and Is Not)#

Fabric is a SaaS product, not a PaaS assembly kit. Because it is SaaS, users never interact with Azure infrastructure concepts such as resource groups, Azure Resource Manager, redundancy settings, or region placement, and an Azure subscription is not a prerequisite for access ^[S1]. Microsoft manages the underlying infrastructure; tenants interact with workspaces, items, capacities, and workloads.

This matters architecturally. Decisions that would consume days in an Azure-native design — networking topology, redundancy zones, resource group scoping — either do not apply or are handled by the service. What remains in the platform engineer's hands is the Fabric-level hierarchy: tenants, domains, workspaces, capacities, items, and the networking overlays (private links, IP firewalls, Conditional Access) that govern how data moves in and out.

Core Architecture: The Three-Layer Model#

Workloads — the functional surface#

Fabric organizes its capabilities into role-oriented workloads: Power BI, Data Factory, Data Engineering, Data Science, Data Warehouse, Databases, Real-Time Intelligence, Industry Solutions, and the preview workload Fabric IQ ^[S1]. Each workload targets a functional area and contributes its own item types, but all run inside the same environment and can share data and items without duplication ^[S1].

In Fabric vocabulary, an item is any object you create — a lakehouse, notebook, warehouse, eventhouse, report, and so on — and each workload contributes its own item types ^[S2]. A workload is the collection of capabilities aimed at one functional area ^[S2].

The shared platform layer#

Beneath the workloads sits a shared platform layer of three services that every experience uses consistently: OneLake for storage, Copilot for embedded AI assistance, and centralized governance powered by built-in Microsoft Purview ^[S1]. Nothing in any workload bypasses this layer; it is what lets a Spark notebook, a T-SQL query, and a Power BI report all operate against the same data without copying it.

The tenancy and workspace model#

A Fabric tenant is a single organizational instance of the service, aligned one-to-one with a Microsoft Entra tenant ^[S2]. Inside the tenant, workspaces act as collaboration containers that hold items, draw compute from a capacity, and control who can access their contents ^[S2].

Domains sit one level above workspaces. They let an organization group workspaces into logical business areas — Finance, Marketing, Supply Chain — giving administrators a management and governance delegation point above the workspace level ^[S2]. Domains are the recommended mechanism for implementing data mesh ownership boundaries within a single Fabric tenant.

OneLake and Delta Lake: The Storage Foundation#

All Fabric workloads store data in OneLake, the platform's single logical data lake. The standard table format across every workload is Delta Lake ^[S2]. Data ingested into Fabric is stored as Delta tables by default, which is what lets different engines read each other's output without format conversion ^[S2].

This is the core interoperability guarantee: a notebook writes Delta to OneLake, and a T-SQL query in the warehouse, a KQL query in an Eventhouse, or a Direct Lake semantic model can all read that data directly — no ETL step, no copy, no format translation required.

OneLake shortcuts extend this further by letting a workspace point to data in external sources — other OneLake locations, ADLS Gen2, S3, and others — and expose it as if it were local lakehouse storage. Inference: this is the mechanism that enables cross-workspace and cross-cloud data reuse without physical data movement.

The Canonical End-to-End Pattern#

The pattern that Fabric is architected around is: ingest with Data Factory, process with the Data Engineering (Spark) or Real-Time Intelligence workloads, and visualize the result in Power BI ^[S1]. No manual service integration is required because all stages share OneLake and the same platform services ^[S1].

Data Factory itself is positioned as a cloud-native, serverless orchestration environment: its underlying compute auto-scales, and it ships with built-in CI/CD and deployment tooling aimed specifically at multi-cloud pipeline scenarios, where source and destination systems span more than one cloud provider ^[S6].

The decision map below walks through how to pick the right engine for a given job — gated first by workspace type, then by the shape of the workload — and shows how every path still converges on the same Delta-backed OneLake store.

This stands in contrast to the pre-Fabric Azure data platform pattern, where teams would wire together Azure Data Factory, Azure Databricks or Synapse Spark, Azure Synapse Analytics, and Power BI Premium, each with its own identity, networking, and storage model.

Materialized Lake Views: Declarative Transformation#

Fabric added a platform-native declarative transformation capability called Materialized Lake Views ^[S4]. The feature entered preview in May 2025 and reached general availability in March 2026, providing functionality analogous to Databricks Lakeflow and Snowflake Dynamic Tables ^[S4].

Materialized Lake Views let engineers define transformation logic declaratively rather than imperatively (as notebook code), with the platform handling execution scheduling and dependency tracking. Inference: this capability fits SQL-expressible, stable business logic that benefits from dependency management and dry-run safety — not complex procedural, ML, or streaming workloads where notebooks remain the right tool.

Licensing and Capacity#

Fabric's licensing model has three dimensions: tenant, capacity, and per-user.

Workspace type (formerly called license mode) determines which kind of capacity backs a workspace and therefore which experiences its users can run ^[S3]. Only Fabric, Trial, and Power BI Premium P-SKU workspace types support all Fabric experiences ^[S3].

Per-user licensing starts automatically: a free Fabric per-user license is granted the first time someone signs in to the Fabric portal when the tenant has Fabric enabled ^[S3]. This free license permits creating and sharing non-Power BI Fabric items in workspaces backed by an F or Trial capacity ^[S3]. Users do not need to explicitly acquire or assign this license.

Capacity SKUs drive the compute budget available to workloads. F SKUs (Fabric capacity) and P SKUs (Power BI Premium) both support Fabric experiences; shared Pro/PPU pools support only the workloads their SKU originally covered ^[S3].

Inference: Organizations beginning a Fabric adoption should evaluate F SKU sizing and workspace type alignment early, because the workspace type gates which experiences are available — a workspace on a Pro pool cannot run Spark notebooks or warehouses.

Cross-Tenant Data Sharing#

Fabric supports cross-tenant data sharing, letting an organization expose live governed datasets to external Microsoft Entra tenants without copying data ^[S1]. Recipients read the data in place and source-side governance policies stay in force ^[S1]. This is relevant to multi-entity enterprises, regulated data partnerships, and ISV scenarios where a data producer must share analytical data with external consumers while retaining control.

Item Recovery: Undoing Accidental Deletion (GA)#

Item Recovery reached General Availability effective June 30, 2026, after a period in Preview ^[S7]. It gives tenant admins and workspace users a safety net against accidental or malicious item deletion.

How it works. When a supported item is deleted, it does not disappear immediately. Instead it moves to a soft-deleted state, and its content, metadata, and permissions remain intact and restorable for the duration of a retention window ^[S7]. Tenant admins can configure that retention window up to 90 days, and can change the window value at any time ^[S7]. Once the window expires, the item is permanently deleted and can no longer be restored ^[S7] — so the window is the operative control surface, not a fixed grace period.

Restoring an item. Recovery is available two ways: through the Workspace Recycle Bin in the Fabric portal UI, or programmatically through a REST API ^[S7]. The API path matters for governance — it means recovery does not have to be a manual, ticket-driven process.

Rolling out Item Recovery: an operational checklist#

The GA guidance gives two concrete rollout recommendations, both backed by verified claims:

• Confirm the tenant setting matches policy. Review and confirm the Item Recovery tenant setting under Fabric admin portal → Tenant settings against organizational retention policy, rather than assuming the default is correct for your compliance posture ^[S7].
• Wire recovery into governance automation. Organizations that already automate audit or compliance workflows are advised to evaluate integrating Item Recovery's REST APIs and audit events into those existing workflows, rather than treating recovery as a purely manual, portal-driven action ^[S7].

# Illustrative REST call pattern for programmatic restore (Inference: illustrates the
# documented REST API restore path; exact endpoint/method names are not themselves
# verified claims -- consult the Fabric REST API reference before scripting this).
POST https://api.fabric.microsoft.com/v1/workspaces/{workspaceId}/items/{itemId}/restore
Authorization: Bearer {token}

Operating the On-Premises Data Gateway (June 2026 Release)#

For tenants that keep data on-premises, the on-premises data gateway is the bridge into Fabric. The June 2026 release, version 3000.322, is focused on gateway manageability, operational visibility, and enterprise governance, while preserving secure connectivity between on-premises sources and Fabric services ^[S8].

Three concrete changes ship in this release:

• Windows Web Account Manager (WAM) authentication support, intended to improve token security and align gateway authentication with Microsoft's modern identity platform ^[S8].
• A consent-driven model for gateway diagnostic uploads, giving organizations explicit control over how operational diagnostic data is shared — intended to speed up troubleshooting when a case is opened, without forcing always-on diagnostic collection ^[S8].
• An updated bundled Apache Log4j library, to version 2.25.4, addressing previously identified vulnerabilities ^[S8].

Using the new diagnostic capabilities requires the gateway to be running the latest version — Microsoft recommends keeping gateways current for both security and troubleshooting benefits ^[S8]. Administrators no longer have to reach for a standalone installer to get there: gateway updates can now be initiated directly from the Manage connections and gateways experience inside Microsoft Fabric ^[S8].

Keeping the gateway updated is now a task you can do from inside Fabric itself, not a separate installer errand.

Fabric Apps and Rayfin: The Emerging Application Surface#

Alongside the analytics and BI workloads, Microsoft has begun building a distinct application layer on top of Fabric. Fabric Apps — the application type built and deployed using a tool called Rayfin — were announced at Microsoft Build ^[S9].

What Rayfin does today. Rayfin lets developers build full applications on top of Fabric data, combining semantic models for analytics with Fabric SQL databases for operational data inside a single application experience ^[S9]. Inference (hedged, tier-6 source): one industry write-up describes Rayfin as an open-source SDK and CLI, announced at Microsoft Build 2026, that provisions a complete application backend onto Fabric capacity from a single command — this framing is consistent with the verified claims above but comes from an unverified secondary source, not Microsoft directly, so treat the specific "single command" mechanic as unconfirmed detail rather than a settled fact ^[S10].

Security model. Rayfin adds its own policy-based authorization layer on top of Fabric's native security, so an application can combine Fabric-level access control with application-specific access policies ^[S9]. Microsoft's recommended security pattern for Rayfin applications is to keep sensitive data and security-critical logic out of frontend code entirely — protected data and access-rule enforcement belong in managed backend services, not in code that ships to a browser or client ^[S9].

# Right: enforce access rules server-side, in a managed backend service
# (Inference: illustrative shape only -- no verified claim specifies exact
# Rayfin API surface or SDK method names)
backend_service.authorize(user_context, resource) -> allow | deny
backend_service.query_semantic_model(resource_id)   # runs only after authorize()

# Wrong: trusting the frontend to gate access
if (frontendConfig.userIsAdmin) {           // client-controlled, spoofable
  showProtectedData();
}

Why this matters: the verified pattern claim exists precisely because the wrong approach above is a real, observed anti-pattern — frontend-enforced access control can be bypassed by anyone who can read or modify client-side code, whereas a managed backend service is the enforcement boundary Fabric's own security model expects ^[S9].

What's shipped vs. what's still planned#

It is important to separate current Rayfin capability from stated future direction, because conflating the two would misrepresent the platform's actual maturity:

Inference (hedged, tier-6 source): a secondary industry guide positions Rayfin as targeting professional, code-first developers and AI coding agents, explicitly distinguishing it from Power Apps' low-code/citizen-developer model, and describes it provisioning an Entra ID-based authentication service as one of three managed child services (alongside a SQL database and static content hosting) from a single deployment ^[S10]. These characterizations come from an unverified vendor blog, not Microsoft, so treat them as plausible context rather than confirmed platform behavior.

AI-Assisted Migration Tooling#

Microsoft has also published open-source, AI-assisted tooling for migrating existing Azure Synapse workloads into Fabric. The Synapse Migration and Pipeline Migration skills are open-source, distributed as part of a public skills-for-fabric GitHub toolkit, installed via command-line setup plus az login authentication, and designed to work with GitHub Copilot, VS Code, Claude, and other AI coding assistants — rather than being a built-in Fabric portal feature ^[S11].

Inference: this positions migration tooling as something a platform team runs from their own developer environment during a migration project, not as an always-on Fabric portal capability end users would discover in the UI.

Governance and Network Security#

Private link options#

Fabric offers two distinct private link scopes ^[S5]:

• Tenant-level private links cover the entire tenant and are generally available since May 2024. They work at any paid SKU. The model is all-or-nothing: once enabled, all Fabric traffic from the tenant must traverse the private network.
• Workspace-level private links restrict private access to individual workspaces and are generally available since October 2025. They are restricted to F SKUs only and allow a mixed public-private deployment where some workspaces are private and others remain public ^[S5].

Conditional Access as an alternative#

For organizations that lack an explicit regulatory mandate for network-level isolation, Conditional Access combined with an IP firewall addresses the dominant risk surface — identity, device compliance, and network location — without the operational constraints imposed by private links ^[S5]. One important constraint: Conditional Access cannot target Fabric in isolation and must cover all dependent service endpoints ^[S5].

Inference: For most organizations, Conditional Access plus IP allowlisting is the operationally lighter path and should be the default choice unless a compliance regime specifically requires network-level isolation.

When private links are the right choice#

Private links are a viable architectural choice only for pure cloud-to-cloud workloads on F SKUs that have no dependency on on-premises data sources, Deployment Pipelines, or Fabric SQL Database, and where Power BI feature limitations are operationally acceptable ^[S5].

What Goes Wrong: Private Link Anti-Patterns#

Private link configuration is an area with well-documented operational traps.

On-premises data gateways stop working. On-premises data gateways cannot register and will not function when tenant-level Block Public Internet Access is enabled ^[S5]. There is no supported configuration for using on-premises data gateways alongside tenant-level private links; the only replacement is a VNet data gateway, which requires Azure networking infrastructure such as ExpressRoute or a site-to-site VPN ^[S5].

Workspace-level restrictions disable specific features. When public access is blocked at the workspace level, Fabric SQL Database, Deployment Pipelines, shortcut transforms, and the Power Platform Dataflow Connector are all unsupported ^[S5]. These are design-level constraints, not configuration gaps, and are unlikely to be resolved by minor product updates ^[S5].

Power BI feature set is reduced. Several Power BI capabilities are unavailable when private links or public-access blocking is in effect: Publish to Web, email subscriptions, PDF and PowerPoint export, and Copilot under tenant-level private links are all unsupported ^[S5]. Power BI modern usage metrics are only partially available under tenant-level private links, capturing Report Open events but not Page Views or performance data ^[S5].

Design checklist before enabling private links:

• Confirm no on-premises data sources require an on-premises gateway (use VNet gateway instead)
• Verify no reliance on Deployment Pipelines or Fabric SQL Database at the workspace level
• Accept Power BI feature gaps: no Publish to Web, no export to PDF/PowerPoint, no email subscriptions
• Confirm Copilot usage under tenant-level private links is not required
• Ensure all workspaces are F SKU if workspace-level private links are chosen

Production Stability Patterns#

Inference (hedged, tier-6 source): the patterns in this section come from a secondary industry write-up, not a Microsoft primary source, so treat them as commonly-cited practitioner patterns rather than official Microsoft guidance — verify against your own environment before adopting wholesale.

One recurring theme across production Fabric deployments is that Git integration is on by default for newly created items — Dataflow Gen2, pipelines, notebooks, semantic models, and Eventstreams all get their definitions stored as plain-text files that are diffable and revertible from the moment they're created ^[S12]. That default matters operationally: it means a team does not have to remember to opt in to source control discipline; the discipline is already there unless someone opts out.

Two further reliability patterns are worth calling out because each pairs a rule with a concrete before/after:

Pattern: idempotent writes with retry-and-backoff. The rule is to combine three retries with exponential backoff for transient failures with idempotent write logic, so that a rerun after a transient failure does not create duplicate records ^[S12].

-- Wrong: plain INSERT -- a retried run after a transient failure
-- duplicates every row from the partially-completed attempt
INSERT INTO sales_fact SELECT * FROM staging_sales;

-- Right: Delta MERGE keyed on a natural/business key -- a retried run
-- is a no-op for rows that already landed, safe to rerun after a
-- transient failure with exponential backoff
MERGE INTO sales_fact AS target
USING staging_sales AS source
ON target.sale_id = source.sale_id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

Pattern: gated environment promotion. The rule is to use Deployment Pipelines to promote items across Dev, Test, and Production workspaces, with Variable Libraries injecting environment-specific connection strings, and a pull-request gate required before promotion to production ^[S12].

Dev workspace  --(Deployment Pipeline promote)-->  Test workspace
     |                                                    |
Variable Library: dev connection strings         Variable Library: test connection strings
     |                                                    |
                                          (PR review + approval gate)
                                                           |
                                                           v
                                              Production workspace
                                     Variable Library: prod connection strings

Without the gate, a promotion pipeline can push an untested change straight to production the moment a pipeline run completes — the PR gate is what turns "promote on merge" into "promote on reviewed merge."

Internals: V-Order Write-Time Optimization#

This section covers the one verified L4 (performance/internals) claim in the fabric-platform knowledge base.

V-order is a write-time optimization applied to the Parquet format that speeds up subsequent reads ^[S2]. All Fabric engines write V-ordered Parquet files by default ^[S2].

V-order works by reordering column data within each Parquet row group to improve compression ratios and enable faster column scan patterns at read time. Because every Fabric engine writes V-ordered files, any engine reading those files benefits automatically — a warehouse query, a Direct Lake column scan, or a Spark read all receive this optimization without any explicit configuration.

Inference: The universality of V-order is a deliberate platform design choice. By baking it into every write path rather than making it a per-engine or per-table option, Fabric ensures that the storage layer is always optimized for the read-heavy analytical workloads that dominate the platform's use cases. Disabling V-order (which is possible) sacrifices read performance for marginally faster writes, a tradeoff that is rarely worthwhile except in high-frequency micro-batch ingestion scenarios where write throughput is the bottleneck.

Worked Example: Ingestion to Reporting#

The following scenario illustrates how the platform concepts above combine in a real deployment. All mechanics described here are supported by verified claims; steps labeled Inference: go beyond what the claims explicitly state.

Scenario: A retail organization wants to load daily sales data from an on-premises SQL Server, enrich it with reference data from a partner's ADLS Gen2 account, and serve a Power BI report to business users.

1. Tenancy setup. The organization's Fabric tenant is already aligned with their Microsoft Entra tenant ^[S2]. An F64 capacity is provisioned, and a workspace of type Fabric is created to back the project ^[S3].

2. Ingestion. A Data Factory pipeline copies the daily sales extract from on-premises SQL Server, using its auto-scaling, serverless orchestration ^[S6], over a VNet data gateway (Inference: required if the tenant uses private links; otherwise an on-premises gateway suffices, running the June 2026 3000.322 release for WAM auth and the newer bundled Log4j ^[S8]). The pipeline lands data as Delta Lake tables in a lakehouse on OneLake.

3. Transformation. Inference: A Spark notebook or, for SQL-expressible logic, a Materialized Lake View ^[S4] enriches the sales data with the partner's reference dimension, which is exposed as a shortcut from the partner's ADLS Gen2 account. The output is a curated Delta table, written with idempotent MERGE logic so re-runs after a transient failure don't duplicate rows ^[S12].

4. Reporting. A Direct Lake semantic model is created against the curated Delta table. Because the file format is V-ordered Parquet ^[S2], column scans during report queries are fast without a full data import. Power BI reports connect to the semantic model.

5. Governance. The workspace belongs to a Retail domain ^[S2], allowing the data platform team to apply domain-level governance policies. Microsoft Purview ^[S1] provides lineage from the source SQL Server through to the report. Git integration on the pipeline and notebook items is on by default, giving the team diffable, revertible item history from day one ^[S12].

6. Operational safety net. Item Recovery is GA and its tenant setting has been reviewed against policy ^[S7]; if a report or pipeline is accidentally deleted within the configured retention window, it can be restored from the Workspace Recycle Bin or via REST API ^[S7] rather than rebuilt from scratch.

All stages share OneLake and the same platform services — no manual integration, no intermediate copies ^[S1].

Internals#

Architecture & design#

Coming soon — this depth isn't in the knowledge base yet. It needs an L4/L5 source such as Fabric control-plane or workspace-runtime architecture documentation describing how tenants, domains, workspaces, and capacities are actually implemented under the SaaS abstraction. Tracked in content/queue.md.

How it works internally#

Coming soon — this depth isn't in the knowledge base yet. It needs an L4/L5 source such as an engineering blog on Fabric's control-plane execution model or capacity scheduling internals. Tracked in content/queue.md.

Performance characteristics#

Coming soon — this depth isn't in the knowledge base yet. It needs an L4/L5 source such as a published Fabric capacity/throughput benchmark or a Microsoft engineering post on capacity unit consumption modeling. Tracked in content/queue.md.