One of the cleanest patterns in Microsoft Fabric is splitting your world in two: a “data product” workspace that owns curated lakehouses, and an “analytics” workspace that owns semantic models and reports. You connect the two with a OneLake shortcut, and suddenly you’ve avoided copies, reduced refresh complexity, and kept your architecture tidy.
Then the first DirectLake semantic model hits that shortcut and… the tables don’t load.
This post walks through what’s really happening in that moment in Microsoft Fabric, what permissions you actually need (and where), and how to tighten the whole pattern with OneLake Security instead of simply widening access. We’ll also cover the easy-to-miss caveat: if your shortcut ultimately lands on a Fabric SQL Database, you still have to do SQL permissions, too.
Why this breaks: the shortcut doesn’t “move” data, it extends your permission surface
The easiest mistake to make is thinking of a shortcut as a convenience feature in the workspace UI. Fabric treats it more like a pointer inside OneLake, and that changes the security conversation.
Two ideas matter here:
Workspace roles are mostly “control plane.” They define what you can do in the workspace (create/edit/manage). They often inherit into item access, but they’re not the whole story for reading data.
Shortcuts are governed by both ends:
- the shortcut path (where the shortcut lives)
- the target path (where the data actually resides)
And Fabric applies the most restrictive permission of the two locations.
So if you have:
- Workspace A: Lakehouse A (contains shortcuts) + Semantic Model A
- Workspace B: Lakehouse B (the shortcut target)
…your semantic model in Workspace A is only as successful as the permissions you’ve set on both Lakehouse A and Lakehouse B.
The permission rule that matters: “both ends, most restrictive wins”
Microsoft’s shortcut security documentation is explicit: accessing a shortcut is governed by permissions on the shortcut path and the target path, and the most restrictive combination applies.
For the scenarios that typically show up with semantic models and lakehouse shortcuts, the key requirements are:
- To read file/folder content through a shortcut: ReadAll on shortcut path + ReadAll on target path
- To read shortcut data exposed as tables through the lakehouse (via the TDS endpoint): Read on shortcut path + ReadAll on target path
If you’re building semantic models that read Delta tables in OneLake (the new DirectLake-on-OneLake pattern), you’ll keep seeing “Read” and “ReadAll” show up because:
- Read is the base ability to see the item metadata (you can “connect,” but not necessarily read data)
- ReadAll is what unlocks OneLake data access (with important caveats when OneLake security is enabled)
The minimal setup: make the semantic model’s consumers able to read the target lakehouse—without giving them the target workspace
Here’s the part most people are relieved to learn: you can grant access to the lakehouse in Workspace B without granting access to Workspace B itself.
Microsoft documents this directly for lakehouses: sharing a lakehouse grants access to the lakehouse without giving access to the workspace and the rest of its items.
That’s exactly the “reader group” pattern you want for cross-workspace shortcuts.
Step 1: decide whose identity is actually reading
This matters more than the UI suggests.
If your semantic model uses user SSO (common for DirectLake): each querying user needs the minimum required permissions to read the underlying data path.
If you bind the model to a fixed identity (more on that later): only that fixed identity needs data access, and end users don’t.
Step 2: confirm access on the shortcut path (Workspace A / Lakehouse A)
The consuming semantic model is reading through Lakehouse A, so it needs to be able to read there.
In practice, most model authors already have this because they’re Contributors or higher in Workspace A. But when you’re intentionally using least privilege (especially for service accounts and “consumer-only” identities), validate that the identity can at least read the lakehouse containing the shortcut.
Step 3: grant Read + ReadAll on the target lakehouse (Workspace B / Lakehouse B) to Workspace A’s reader group
This is the crux of your scenario.
In Workspace B (the target workspace), go to the target lakehouse → Manage permissions (or Share), and add the security group you use as the Reader group for Workspace A (or your “semantic model consumers” group). Grant:
- Read
- ReadAll
Two important details make this work the way you want:
ReadAll is often required to read OneLake data, but it doesn’t stand alone. Microsoft calls out that ReadAll requires Read (or Viewer role) as a prerequisite—ReadAll by itself does not grant access.
Because you’re granting item permissions (sharing), the group gets access to the lakehouse (and its SQL analytics endpoint), but does not become a member of Workspace B. This is exactly how you grant data access without “opening” the producer workspace.
At this point, your semantic model in Workspace A can read through the shortcut to Workspace B—because the identities that query the model have permission at the target path.
How to make this more secure (without giving up the shortcut pattern)
Granting Read + ReadAll is functional—but it’s not the end game if your lakehouse contains anything sensitive. The goal is to keep the shortcut architecture while shrinking the blast radius.
Use OneLake security to restrict what ReadAll can see
OneLake security (preview) is designed for exactly this: applying role-based access at the table/folder level in OneLake, consistently across Fabric engines.
Two practical points to keep you from thinking it’s “on” when it isn’t:
When you enable OneLake security, Fabric creates a DefaultReader role so users who previously had read access keep working. Users with ReadAll are included in that default role unless you change it. To start restricting access, you delete DefaultReader or remove ReadAll from users who shouldn’t see everything.
OneLake security roles apply to users who are Viewers or have Read on the item; Admin/Member/Contributor roles are not restricted the same way. If you’re serious about enforcement, avoid granting elevated workspace roles to your consumer identities.
A strong pattern here is: share the lakehouse to the consuming group (Read + ReadAll), then use OneLake security roles to limit them to only the tables/folders the semantic model should expose.
Don’t try to “secure the shortcut” downstream
For OneLake-to-OneLake shortcuts, passthrough is supported and the source retains control. In plain language: you don’t secure the target data by changing permissions on the downstream lakehouse that contains the shortcut. You secure it at the source location.
That’s good governance: ownership stays with the producer workspace.
Use a fixed identity for the semantic model when you don’t want users to touch the lakehouse at all
If your objective is “users can query the semantic model, but they cannot directly query the lakehouse or browse OneLake,” DirectLake supports a pattern where you bind the model to a cloud connection with a fixed identity and disable SSO—then you don’t grant end users permissions on the data item.
This isn’t the lightest-weight option operationally, but it’s a clean way to separate “semantic model consumption” from “data lake access.”
The SQL caveat: shortcuts don’t magically grant SQL permissions
Now the gotcha you asked to call out.
If your shortcut points to a Fabric SQL surface (Warehouse or a SQL analytics endpoint scenario), you still have to think like a database administrator.
Microsoft’s warehouse sharing guidance makes this very clear:
- Sharing with only Read is effectively CONNECT; it lets a user connect but not query tables. To query objects, you must grant access with T-SQL
GRANT. - ReadData (SQL access) and ReadAll (OneLake/Spark file access) are separate and do not overlap.
So if you shortcut to something that is ultimately accessed via SQL, plan to set SQL permissions (GRANT SELECT on schemas/tables, roles, etc.) in addition to the OneLake-side permissions.
And if you’re using OneLake security with SQL analytics endpoints, be aware there are two modes:
- In User identity mode, table access is governed by OneLake security roles and SQL GRANT/REVOKE on tables isn’t allowed.
- In Delegated identity mode, table access is managed with SQL permissions (GRANT/REVOKE).
Either way, the shortcut doesn’t remove the need to intentionally manage SQL access. It just makes the path to the data easier.
Conclusion: treat cross-workspace shortcuts like a data product contract
If you remember only one thing, remember this: a shortcut is a pointer, and pointers come with permission chains.
To let a semantic model in Workspace A use a lakehouse shortcut into Workspace B, you need permissions on both ends. The practical, least-privilege move is to grant Read + ReadAll on the target lakehouse to the consuming workspace’s reader group—giving access to the lakehouse without granting access to the workspace itself.
From there, you can harden the pattern: restrict what “ReadAll” means with OneLake security roles, avoid elevated workspace roles that bypass enforcement, and consider fixed identities when you want to keep end users out of the lake entirely. And when Fabric SQL is involved, don’t skip the SQL layer—shortcuts don’t replace GRANT SELECT.
If you’re standardizing Fabric architecture across teams, this is a great place to formalize a reusable “data sharing contract”: a dedicated consumer group, item-level sharing, and a OneLake security role that matches your semantic model design.
