There’s a familiar tension in modern analytics: teams want data products that are easy to discover and safe to consume, but they also want to move fast—often faster than the governance model can tolerate.
In Microsoft Fabric, that tension frequently shows up as a perception of workspace sprawl. A “single product per workspace” model is clean on paper—strong boundaries, tidy ownership, straightforward promotion—but it can quickly turn into dozens (or hundreds) of workspaces to curate, secure, and operate.
This post proposes a different pattern—an advanced lakehouse approach that treats the lakehouse itself like a product factory:
- Shortcuts or schema shortcuts become the input layer (a clean, contract-aware “ingest without copying” boundary).
- A small-step transformation layer is implemented as a multi-step DAG using Materialized Lake Views (MLVs).
- A versioned, schema-based surface area becomes the data product contract you expose to consumers.
Then we connect that to OneLake security and Fabric domains, showing how you can expose left-shifted data products (usable earlier in the lifecycle) without letting workspaces multiply endlessly.
Why this pattern exists
If you’ve ever tried to operationalize a portfolio of data products, you’ve likely hit at least one of these:
- You want consumers to start using data earlier (left-shifted), but you don’t want “raw everything” to become the default interface.
- You want isolation and clear contracts, but you don’t want every contract to require a new workspace.
- You want a promotion story (Dev → Test → Prod) that doesn’t require heroic coordination every sprint.
Fabric’s feature set has matured enough that you can build product-shaped lakehouses directly—especially with OneLake shortcuts, lakehouse schemas, and MLVs. This is where data products and Microsoft Fabric stop being a slide deck and start being an engineering design.
The advanced lakehouse: a product-shaped architecture inside one workspace
Think of the lakehouse as a three-layer product engine. Not “bronze/silver/gold” as a philosophy, but as a concrete mechanism you can implement and secure.
Shortcuts and schema shortcuts as the input layer
OneLake shortcuts are explicitly designed to let you unify data across domains, clouds, and accounts under a single namespace—without creating edge copies and staging delays. They behave like symbolic links: deleting a shortcut doesn’t delete the target data, and any engine that can read OneLake can read the shortcut as if it were just another folder.
Within a lakehouse, shortcuts in the Tables area can point to a single table or a schema (a parent folder containing multiple Delta tables).
Lakehouse schemas add an important refinement here: schema shortcuts let you reference multiple Delta tables from another lakehouse schema or from an external folder of Delta tables (for example, ADLS Gen2). Any changes in the source tables show up in the schema shortcut, and Fabric creates a schema in your lakehouse that presents those referenced tables.
That schema shortcut behavior is the foundation of a clean “input layer,” because it creates a stable place to say:
“These are the upstream tables we are intentionally consuming.”
This is also where #OneLake becomes more than storage—it becomes a practical interface for composable inputs.
A small-step transformation DAG with Materialized Lake Views
Materialized Lake Views (MLVs) are not just “views that materialize.” In Fabric, they are precomputed, stored results of SQL queries that can refresh on demand or on a schedule, and Fabric manages dependency ordering and refresh strategy.
That matters for a product pattern because you can move away from “one giant transformation job” and toward small, composable steps:
- standardize types
- apply business rules
- conform dimensions
- add quality constraints
- publish curated entities
And because MLVs support dependency management, your multi-step flow becomes a DAG the platform can understand and run in the right order.
Even better: in the MLV lineage experience, shortcuts are treated as source entities, and any tables/MLVs under a shortcut schema are treated as sources as well.
That is exactly the mental model you want for an input layer: “sources are sources,” even if they’re virtualized.
One nuance worth calling out: Cross-lakehouse lineage and execution features are not available (at least in the current state of the feature).
That pushes this architecture toward “keep the transformation DAG inside the lakehouse that owns the product surface,” rather than spreading the DAG across many lakehouses.
A versioned, schema-based surface area as the contract
Lakehouse schemas are straightforward but powerful: they let you group tables for data discovery and access control, and they introduce a clean namespace pattern for referencing tables (including cross-workspace Spark SQL).
The contract move is simple:
- Treat schemas as product surfaces
- Treat schema versions as compatibility boundaries
A practical naming approach is to use schemas like:
productname_v1(stable contract)productname_v1_internal(optional “left-shifted” intermediate)productname_v2(new contract, side-by-side)
This is not something Fabric enforces for you—it’s a product design choice. But lakehouse schemas give you the mechanism to make it real, and schema shortcuts give you a clean way to ingest upstream tables into a dedicated input schema.
The end result is a lakehouse that behaves like a product:
- Inputs are explicit (shortcuts/schema shortcuts)
- Transformations are explicit and observable (MLV DAG)
- Outputs are explicit and versioned (schemas)
Another place this becomes powerful is that you can change the destination of a shortcut. For the consuming team, once they’ve validated that the new version works or modified their code to support it, they can switch the schema shortcut over and consume the new version. This is the heart of a concept from software service design called loose coupling, which means that downstream services aren’t forced to be updated every time something upstream is. It contains modification blast radius and prevents unexpected failures.
Domains for organization, OneLake security for control
Now we zoom out: the architecture above is “inside the workspace.” The sprawl problem is “how many workspaces do we need?”
Domains give you the “big bucket” without changing access
Fabric domains are explicitly designed for data mesh-style organization and discovery. A key detail is that workspaces are associated with domains, and when a workspace is associated, all items inside inherit the domain attribute for discovery and filtering (for example in the OneLake catalog).
But domain assignment is not a security boundary. Microsoft’s documentation is direct: domain assignment doesn’t affect item visibility or accessibility—access is driven by workspace roles and item permissions, not the domain.
So: domains help you organize and find; they don’t secure.
That’s why you need OneLake security.
OneLake security lets you expose “left-shifted” surfaces without handing out the workspace
OneLake security introduces a data access control model where:
- Workspace roles are the first security boundary, granting broad abilities depending on Admin/Member/Contributor/Viewer.
- Within a workspace, items can have permissions configured separately, and OneLake security roles can grant access to specific tables and folders.
- Viewers, by default, don’t have OneLake data access unless you grant it via OneLake security roles.
This is the core trick for left-shifted data products:
You can keep a single domain workspace, but expose multiple “product surfaces” (schemas) with different OneLake security roles, including intermediate surfaces that would normally be “too raw” to publish broadly.
In other words, you can give some consumers access to productname_v1_internal (left-shifted), while most consumers only see productname_v1. The workspace doesn’t multiply; the surfaces do.
Shortcuts reinforce ownership boundaries in a healthy way
Shortcut security is often misunderstood, and it matters a lot in a product model.
Fabric’s shortcut security model applies the most restrictive permissions between the shortcut path and the target path—so you can’t “shortcut around” governance.
Also, for OneLake-to-OneLake shortcuts, passthrough mode is supported: the source system retains control, and downstream shortcut security can’t be modified independently—changes must be made at the source.
That’s a feature, not a limitation, when you’re building composable #DataMesh-style products: upstream owners keep control, downstream products consume intentionally.
Keeping workspace sprawl under control: the domain-workspace data product portfolio
Here’s the practical position for this approach:
A workspace is a collaboration and governance boundary, not automatically “a data product.”
So instead of “one workspace per product,” you can aim for:
- One workspace per domain (per environment) as the stable unit of organization
- Multiple data products inside the workspace as versioned schema surfaces
This aligns with how Fabric domains work (workspaces associate to domains for discovery), and it aligns with how OneLake security works (granular access inside a workspace).
The pattern looks like this:
- Domain workspace: Finance (Dev/Test/Prod)
- Lakehouse:
finance_lh - Input schema(s): schema shortcuts to authoritative sources (
src_erp,src_crm, etc.) - Transformation schemas: small-step MLV outputs (
finance_stage) - Product schemas: versioned contracts (
ar_v1,ar_v2,revenue_v1, etc.) - OneLake roles: mapped to those schemas/tables by consumer group
This is how you can expose left-shifted products without creating a workspace for every surface you want to share.
How this complements (and sometimes replaces) “single-product per workspace”
The single-product-per-workspace concept is still valid. It’s clean, and it reduces the chance that unrelated teams accidentally collide.
But the domain-workspace approach becomes attractive when:
- your data products share a lot of common sources and transformation logic
- you want consistent governance and naming across a portfolio
- you want consumers to browse a domain’s catalog without chasing workspaces
- you want fewer operational “containers” to manage
In practice, many organizations end up using both:
- Domain workspaces for curated portfolio delivery
- Isolated workspaces for sensitive products, experimental work, or teams that truly require separation
That hybrid is often the realistic enterprise landing zone.
Tradeoffs you should be honest about
A domain-workspace portfolio buys you fewer workspaces, but it shifts complexity into lifecycle management and control.
Version control gets more nuanced
Git integration is workspace-scoped, and there are practical constraints. Fabric’s Git integration documentation notes that workspaces can contain a maximum of 1,000 items, and if the Git branch has more than that, syncing fails (with suggested strategies like splitting artifacts across workspaces or organizing into different folders/branches).
That matters if your “domain workspace” becomes a dumping ground.
Also, lakehouse Git integration has a critical nuance: only the lakehouse container artifact is tracked in Git in the current experience, while tables and folders aren’t tracked/versioned the same way.
Shortcuts are treated differently: shortcut definitions are stored and tracked in a shortcuts.metadata.json file and are synchronized into the workspace.
So if your “versioned schema surface area” relies on physical table creation and DDL, you’ll likely need to treat those definitions as code (notebooks, Spark SQL scripts, automation), rather than assuming Git will version every object automatically.
Promotion pathways can be less “one-click simple”
Deployment pipelines support moving content between stages, and Fabric explicitly supports both full deployment and selective deployment.
In a single-product workspace, selective deployment is often easy: most things belong to the product.
In a domain workspace, selective deployment becomes a discipline. You need conventions to avoid accidentally promoting unrelated product changes in the same wave.
There’s also a strong operational implication: promotion often moves artifacts, not data. That’s why shortcuts as an input layer are so valuable—they can “point” each stage at the right data location, and Fabric’s lakehouse lifecycle docs recommend using variables when a shortcut needs to target different locations per stage.
Security boundaries are powerful—but not absolute
OneLake security can be very granular, but the workspace boundary still matters: Admin/Member/Contributor roles are broad, and workspace roles remain the first control plane boundary.
So if your intent is “product teams must not see each other’s work,” a single shared domain workspace can be a poor fit. You either need stricter workspace membership design, or you need separate workspaces.
Closing thoughts
This advanced lakehouse pattern is not about rejecting “one product per workspace.” It’s about acknowledging the reality that data product portfolios don’t scale well if every product requires its own workspace, its own ALM, its own security story, and its own governance overhead.
By using:
- shortcuts/schema shortcuts as an explicit input layer,
- Materialized Lake Views for small-step, observable transformation DAGs,
- versioned schemas as a contract surface,
- and OneLake security to expose only what each consumer should see,
…you can ship left-shifted, product-shaped data capabilities inside a domain workspace—then use Fabric domains for discovery and organizational clarity without pretending they solve security.
If you’re trying to get real traction with a domain-oriented data platform, this is a practical way to make progress without letting the workspace count become the story.
