Currently, data consumers always need to use the Lakehouse shortcut when reusing an organisation's data.
Enabling cross-workspace query in the Warehouse will enable data engineering in T-SQL directly when reusing an organisation's data
6 Comments
- TwinkleCyril
Microsoft Employee
Status changed:NewtoPlannedThanks for this idea and the detailed scenarios - cross-workspace data access is something we're actively investing in.
Where we are today:
• Cross-warehouse queries work within a single workspace (three-part naming across warehouses/SQL endpoints in the same workspace).
• Across workspaces, a Lakehouse shortcut can bridge the data, but we recognize that adds management overhead.
What's planned:We're building Table & Schema Shortcuts in the Fabric Warehouse, which will let you surface tables from another workspace's Warehouse/Lakehouse directly inside your Warehouse and query them with standard T-SQL, no pipeline copy or separate Lakehouse bridge required. This directly targets the cross-workspace read scenario described here (e.g., raw data in workspace A, transformations in workspace B).
The feature is progressing through preview and is expected to land in November 2026. We'll update this idea as milestones land.Please keep the comments coming.
- TomDeneyerNew Member
Hello TwinkleCyril,
This would be fantastic!
I see it's been 2months since it changed to "planned", do you have any idea when it will be live ?
Thank you :)
Best regards,
Tom.
- MartjanRegular VisitorHaving a warehouse item shortcut that references a warehouse in another workspace would make this possible. Ideally the target workspace and warehouse as shortcut item parameters in a varlib.
- marlabs-bshreveNew Member
This is crucial functionality for dbt users working with Fabric. I'm hitting the same issue in my implementation.
The current setup is frustrating - I can move data between workspaces with pipelines but can't directly query across workspaces. This kills a clean implementation for data privacy requirements where:
- Raw data lives in workspace A with masking and viewer-only access
- Transformed data belongs in workspace B
- dbt needs to read from A but write to B
The workarounds all feel hacky:
- Shortcuts work but add complexity and management overhead
- Cross-warehouse queries only function within the same workspace
- Data Pipelines require completely different tooling/orchestration
- Notebook T-SQL queries are possible but that's another thing to maintain
Bottom line: If I'm a member of both workspaces, I should be able to read from one and write to another in the same dbt process. This would align with dbt's core philosophy of modeling data where it belongs while respecting security boundaries. Has anyone found a cleaner solution than shortcuts? Would love to see the dbt-fabric adapter support configuring separate source/target workspaces in profiles.yml.
- frithjof_v
Community Champion
I wish it was possible to reference tables in other workspaces like [workspaceName].[warehouseName].[schemaName].[tableName] when using T-SQL. I want to avoid using Lakehouse shortcuts due to the overhead of creating and managing them, and the potential for SQL Analytics Endpoint sync delays. - fbcideas_migusrNew MemberStatus added:New
Recent ideas
Select Entire Hierarchies in Power BI Personalize Visuals
Feature Request: Select Entire Hierarchies in Power BI Personalize Visuals Hi Power BI Team, I'd like to suggest an enhancement to Personalize Visuals that allows users to select an entire hierarch...davejames128 hours agoNew MemberNew10Views1like0CommentsFile level commit - Need the ability to edit the commit description
I tried the recently announce file level commit for Fabric items. One notable issue I have with the feature (testing this with a Fabric warehouse, I'm assuming this would hold true for other items): ...DataBard8 hours agoMost Valuable ProfessionalNew31Views0likes2CommentsRename notebook cell name “SparkR (R)” to “R” and “PySpark (Python)” to “Python”
It's a simple idea. In Fabric notebooks, the cell language for R is labeled “SparkR (R)”. Since Spark 4.0, the SparkR package is deprecated, and the Fabric Runtime 2.0 documentation itself notes th...lorin_s10 hours agoNew MemberNew12Views0likes0CommentsAuto Display Unit Feature in Visuals
Hi Team I have a concern regarding the Auto feature of the display unit in Power BI. Regardless of the resizing of visuals (e.g., bar chart, line chart, etc.), the Auto feature should work as expect...Anonymous10 hours agoNot applicableNew426Views18likes3CommentsAuto Display Units Should Dynamically Change Granularity
When auto is selected for display units, the granularity should automatically change to best suite the size of the data. For example, we often have charts that have numerical ranges from the milli...acason10 hours agoNew MemberNeeds Votes353Views26likes5Comments