Summary: When using Snowflake-managed Iceberg tables with an ADLS Gen2 external volume, Fabric requires a manual table shortcut for each Iceberg table. Worse, when the Iceberg table is recreated (e.g., via dbt CREATE OR REPLACE TABLE), Snowflake writes to a new folder with a new unique suffix (e.g., MyTable.ob8ZlxyE → MyTable.Kx9mP2qR). The existing Fabric shortcut continues pointing to the old folder, showing stale data. This requires manual shortcut recreation after every table rebuild — making the ADLS approach impractical for automated dbt pipelines. The OneLake Direct approach (Snowflake database item) handles this automatically, but it has two significant limitations: (1) it requires Snowflake and Fabric to be in the same Azure region, and (2) it locks the data into OneLake as the sole storage location. Writing Iceberg data to ADLS instead of OneLake enables a multi-consumer architecture — the same Iceberg tables can be read by Fabric, SAP Business Data Cloud, Databricks, Spark, or any other Iceberg-compatible engine without granting each system access to OneLake. This is one of the core value propositions of the open Iceberg format: write once to neutral storage, read from anywhere. Forcing data into OneLake to get automatic table discovery reduces Iceberg to a 1-to-1 integration between Snowflake and Fabric, negating much of its benefit as an open table format.   Requested Capability: Automatic Iceberg table discovery and shortcut resolution for ADLS Gen2-backed storage, so that Fabric stays current when Iceberg tables are recreated at new paths. Possible Implementation Paths: Add Iceberg support to schema shortcuts — Schema shortcuts already auto-discover Delta tables in a folder. Extending this to trigger Iceberg-to-Delta virtualization (the same conversion that individual table shortcuts already perform) would allow a single schema shortcut pointed at an ADLS folder to automatically surface all Iceberg tables — and resolve to the current folder when tables are recreated. Allow Snowflake Database Item to work with ADLS external volumes — Today, creating a Snowflake database item in Fabric with an ADLS-backed external volume fails with InvalidExternalVolumeConfiguration: External volume has invalid OneLake URL. Removing the OneLake URL restriction would let ADLS-backed Iceberg tables use the same automatic discovery that OneLake Direct already provides. Fabric would query Snowflake's catalog for metadata (resolving the current folder path) and read data files from ADLS. Support an Iceberg REST catalog as a shortcut source — Allow Fabric to connect to a standard Iceberg REST catalog endpoint (e.g., Snowflake Open Catalog / Polaris) and auto-discover tables. This would decouple Fabric from any specific storage path and work with any Iceberg catalog provider, not just Snowflake. Business Impact: ADLS-backed Iceberg tables enable a multi-consumer data architecture where Snowflake writes once and multiple platforms — Fabric, SAP, Databricks, and others — can each read from ADLS independently. This avoids duplicating data into each platform's proprietary storage and is the intended use case for the open Iceberg format. Without automatic table discovery for ADLS, organizations must either: (a) restrict dbt to incremental materialization only (no full rebuilds), (b) build custom automation using the Fabric Shortcuts REST API to recreate shortcuts after every dbt run, or (c) abandon ADLS and write to OneLake, accepting a 1-to-1 Snowflake–Fabric integration that excludes other consumers. All three add cost, operational complexity, or architectural compromise.   Environment Details: Snowflake (East US 2) writing Iceberg V2 tables to ADLS Gen2 via external volume dbt managing table materializations (CREATE OR REPLACE TABLE) Fabric Lakehouse with schema-enabled shortcuts Tested June 2026 ... View more