🛠️ Field Questions — Real Customer Scenarios¶ Reference

Last Updated: 2026-05-21 | Version: 1.0.0

This page collects detailed answers to specific questions raised during enterprise Fabric adoption — scenarios that the standard product docs don't address directly but that come up repeatedly in field engagements. Each topic links back to the authoritative Microsoft Learn citation.

1. Power BI Mashup Errors with Mixed VNet + Cloud Sources¶

Scenario. Combining data from Azure Databricks (on a corporate VNet) with cloud data sources such as SharePoint Lists causes the Power BI semantic model refresh to fail. The mashup engine appears to be routing the cloud source through the VNet.

Why this happens¶

This is the Power Query Formula.Firewall ("privacy levels which cannot be used together") error. Power Query partitions every data source by privacy level and refuses to evaluate a single mashup that joins partitions it can't isolate.

In the Power BI Service the constraint is stricter still: if any source in a semantic model requires a gateway (VNet data gateway in your case), the service forces the cloud source through the same gateway too — and a single semantic model can use only one gateway connection. SharePoint List → Databricks-on-VNet hits this directly.

To make the cross-source mashup work without changing architecture, you must:

1. Set both sources to Organizational privacy level (Service and Desktop), AND
2. Define the cloud source on the same VNet data gateway, AND
3. Enable "Allow user's cloud data sources to refresh through this gateway cluster" on the gateway.

Source: Data refresh — Accessing on-premises and cloud sources in the same source query · Merge or append on-premises and cloud data sources.

Does mirroring Databricks via VNet to Fabric eliminate the mashup issue?¶

Yes — in practice. Once Azure Databricks is mirrored into a Fabric workspace (through a VNet data gateway), Power BI no longer reads Databricks as a "VNet source" inside the semantic model. The model reads the mirrored Delta tables from OneLake via Direct Lake — which is a Fabric/OneLake source, not a VNet source. SharePoint can then be joined as a normal cloud source without triggering the firewall.

Mirroring for Azure Databricks specifically uses a VNet data gateway (not Fabric's managed private endpoints — those are a separate path for Spark egress). For Databricks behind a private endpoint, follow the dedicated mirroring + private-endpoint guide.

Source: Connect to Azure Databricks workspaces behind a private endpoint · Mirroring Azure Databricks Unity Catalog — Direct Lake.

Does the Fabric workspace need its own Fabric VNet if the Databricks connection is already VNet-private?¶

No — not for mirroring. Mirroring uses the VNet data gateway path. Fabric's managed VNet + managed private endpoints are required only for Fabric Data Engineering (Spark) workloads that need to egress to private resources directly from the workspace.

If your only private source in this workspace is Databricks → ADLS via mirroring + VNet gateway, you do not need to assign a managed VNet to the workspace. You would need it if a notebook in the same workspace later needs to reach the same Databricks/ADLS privately (independent of mirroring).

Source: Managed private endpoints overview — limitations.

Recommended pattern¶

[Azure Databricks (corporate VNet)]
        │
        │  Mirroring via VNet data gateway
        ▼
[Fabric workspace · Mirrored DB item]
        │
        │  Direct Lake (OneLake)
        ▼
[Power BI semantic model]
        ▲
        │  Cloud source — no gateway needed
[SharePoint List / cloud data]

The semantic model now combines two OneLake/Fabric-native sources from its own perspective, so the Formula.Firewall path is irrelevant.

2. Creating Views on Mirrored Databricks Tables¶

Scenario. EDW group uses a two-step Databricks pattern: a Cleaned catalog of tables, plus a Replicas catalog of Views that filter current_record = true and that Analytics consumes. Can the View pattern carry over to Fabric mirroring?

Can you create SQL Views on mirrored Databricks tables?¶

Yes. Every mirrored Azure Databricks item gets an auto-generated SQL Analytics Endpoint that supports T-SQL CREATE VIEW, inline TVFs, stored procedures, and security policies over the Delta tables.

The endpoint label "read-only" refers to data manipulation (no INSERT / UPDATE / DELETE on the mirrored tables themselves). Metadata DDL for views, TVFs, stored procedures, and permissions is explicitly supported — and is documented consistently across every mirroring source (Azure SQL, SQL Server, PostgreSQL, Oracle, Open Mirroring, Databricks).

So your Replicas view pattern translates one-for-one. Create:

CREATE VIEW Replicas.Customer AS
SELECT * FROM Cleaned.Customer WHERE current_record = true;

Source: Mirroring Azure Databricks — Built-in analytics experiences · Explore data in your mirrored database · SQL analytics endpoint limitations.

Where does the transformation belong?¶

In order of recommendation:

For the current_record = true use case specifically, option (A) is the right default — it's a simple WHERE clause, no perf penalty, and it lets you stop maintaining the Replicas catalog in Databricks.

Source: Query the warehouse or SQL analytics endpoint — Write a cross-database query · Develop and deploy cross-warehouse dependencies.

Should you convert mirrored Databricks tables into Lakehouse tables?¶

Usually no. The mirror is incremental and continuously updated. Materializing into a Lakehouse means:

• You now own a refresh schedule (Fabric Pipeline / Notebook) to keep it fresh.
• You lose the near-real-time guarantee of the mirror.
• You double your storage cost for the same logical dataset.

Only do this if (a) you need very heavy aggregations that hurt Direct Lake at query time, (b) you need to mutate the data (e.g., apply additional filtering, deduplication, or business logic that views can't express cleanly), or © you need to blend with other Lakehouse-resident data and prefer a unified storage location.

3. Lakehouse Security and Permissions for Mirrored Databricks¶

Scenario. Customer uses Databricks table-level scripting as a workaround for the lack of "grant all except" functionality. They want to know how the permission model changes once Databricks is mirrored to Fabric.

Are Unity Catalog permissions inherited when mirroring to Fabric?¶

No. Unity Catalog grants are not carried over. Microsoft documents this explicitly: "Unity Catalog policies and permissions aren't mirrored in Fabric. ... You need to use Fabric's permission model to set access control on objects in Fabric."

A single connection credential is used to mirror Unity Catalog. Once the data is in Fabric, downstream consumers query through that connection — Unity Catalog row/column/ABAC policies do not apply to Fabric reads.

A preview pattern called OneLake Security mapping lets you sync an Entra group via Databricks Automatic Identity Management, grant it UC privileges, and then assign the same Entra group a OneLake Data Access Role in Fabric. That is a parallel re-grant, not inheritance.

Source: Secure Fabric mirrored databases from Azure Databricks · Tutorial: Enable OneLake Security.

Three control planes to keep distinct¶

A user needs (workspace role OR item Read) AND sufficient SQL grants to return rows. Unity Catalog is a fourth, fully separate control plane that does not flow through.

Does the endpoint support standard T-SQL grant/deny patterns?¶

Yes. The SQL analytics endpoint over a mirrored database supports the standard SQL Server securable hierarchy via GRANT / REVOKE / DENY, plus RLS and CLS:

-- Grant whole schema
GRANT SELECT ON SCHEMA::abc TO [Analytics-Readers];
-- Deny a specific object
DENY  SELECT ON OBJECT::dbo.xyz_pii TO [Analytics-Readers];
-- Column-level
GRANT SELECT ON dbo.customer (id, name, region) TO [Analytics-Readers];
-- Row-level via security policy
CREATE SECURITY POLICY rls.region_filter
  ADD FILTER PREDICATE rls.fn_region([region]) ON dbo.customer
  WITH (STATE = ON);

Caveats:

• CREATE USER isn't invoked explicitly — the user is created the first time you GRANT / DENY against it.
• The user must additionally have Read on the item (or a workspace role) to connect.
• RLS / CLS apply to T-SQL queries. Direct Lake falls back to DirectQuery to honor RLS, so plan for the perf delta.
• Grants must be re-applied on the SQL analytics endpoint even if defined on the source — they do not migrate via deployment pipelines.

Source: SQL granular permissions in Fabric · Row-level security in Fabric.

Are Entra ID groups supported?¶

Yes — at every layer.

• Workspace roles: Microsoft 365 groups, security groups, and distribution lists are all accepted. Nested groups are honored.
• Item permissions / Share: Entra groups accepted; permission propagation can lag up to two hours.
• SQL endpoint T-SQL: GRANT / DENY accept Entra groups directly:

  GRANT SELECT ON SCHEMA::sales TO [Sales-Analysts];   -- Entra group
  

Source: Roles in workspaces in Microsoft Fabric · Fabric Data Warehouse security.

Which group owns the mirrored Databricks workspace — EDW or Analytics?¶

EDW (data platform team). Microsoft's adoption guidance calls the mirrored database a "data product"; ownership goes to whoever owns the upstream source. The Analytics team gets a separate consumption workspace (Power BI semantic models, reports, paginated reports).

Use Fabric Domains to group both workspaces under a single business domain so the Analytics team gets discoverability without ownership.

Important caveat: shared recipients access using the item owner's identity in delegated mode — if the EDW owner is removed from the workspace, downstream Analytics consumers lose access. Set the owner to a service principal or Workspace Identity, not an individual.

Source: Fabric adoption roadmap — Content ownership and management · Domains best practices · Share warehouse — manage permissions.

How does UAT work when only PROD is mirrored?¶

Microsoft's recommended pattern is mirror once, share everywhere — but that doesn't mean "only mirror PROD." For Fabric-side validation:

1. Upstream Databricks maintains separate UAT and PROD Unity Catalogs (the real data isolation lives upstream).
2. In Fabric, mirror each Databricks environment once into a dedicated mirroring workspace (mirror-databricks-uat, mirror-databricks-prod).
3. Downstream consumer Fabric workspaces (semantic models, reports) are promoted UAT → PROD via Deployment Pipelines, with Data Source rules re-pointing them at the appropriate mirror.

Mirroring is excluded from Deployment Pipeline content promotion (only the item definition is captured in Git; the SQL endpoint and views are not). You must manually start the mirror after deploying to a new environment.

If you mirror only PROD, your UAT consumers can't validate the same query path (SQL endpoint behavior, RLS, view definitions, semantic-model framing) that PROD will use — explicitly mirror UAT too if your release gate requires it.

Source: CI/CD for mirrored databases in Fabric · Fabric deployment patterns.

4. Fabric Workspace Setup for Analytics on Mirrored Databricks¶

Scenario. Analytics group wants to maintain its own Lakehouse to blend Databricks data with non-core systems, then use Direct Lake for reporting.

What can / can't you do against a mirrored Databricks database?¶

Source: Limitations: Fabric mirrored databases from Azure Databricks · Query mirrored databases in Spark notebooks.

Can a single semantic model combine Direct Lake against both a mirror and a Lakehouse?¶

Yes — but only with Direct Lake on OneLake.

Direct Lake on OneLake reads Delta files directly from OneLake (the mirror lands in OneLake), bypassing the SQL endpoint for data load. For the Analytics team's use case — blending Databricks-mirrored tables with non-core sources — Direct Lake on OneLake is the right model.

Source: Direct Lake overview — Comparison of storage modes · Direct Lake on Power BI Desktop.

Do customers typically run Warehouse / Lakehouse and Reports in separate workspaces?¶

Yes — this is Microsoft's documented "data workspace vs reporting workspace" pattern, often layered under a Fabric Domain. The Power BI implementation planning guide recommends separating:

• Data workspace — lakehouses, warehouses, SQL DBs, pipelines, dataflows, semantic models (the data product)
• Reporting workspace — reports, dashboards, metrics (the consumption layer)

For multi-medallion teams, this can further split into Bronze workspace, Silver/Gold workspace, and Reports workspace per data product, with OneLake shortcuts as the cross-workspace glue.

Source: Power BI implementation planning — Workspace-level planning · Fabric deployment patterns.

Can a report's semantic model in Workspace A query a mirrored Databricks in Workspace B?¶

Yes — this is the standard Direct Lake pattern.

Hard constraints:

• Region: model and source must live in the same region. Workaround: create a Lakehouse in the model's region and shortcut to the cross-region source.
• Permissions the binding identity (see service-account section below) must have:
• Read on the mirrored DB item in Workspace B
• ReadData (Direct Lake on SQL) or ReadAll / OneLake Security role (Direct Lake on OneLake)
• Semantic-model owner must also have read access — framing is checked against the owner, not the runtime user.
• If Workspace Outbound Access Protection (preview) is enabled, you must add explicit exception rules (SQL FQDN or OneLake URL).

Source: Direct Lake security integration · Workspace outbound access protection for semantic models.

Does this require a service account?¶

Either SSO or a fixed identity works — but a fixed identity is the recommended pattern for cross-workspace and embedded scenarios.

For the Analytics team's scenario (their own workspace consuming the EDW team's mirror), the recommended pattern is:

1. EDW team creates a Workspace Identity for the mirror workspace.
2. Workspace Identity is granted Read + ReadData on the mirror.
3. Analytics team's semantic model is bound to a connection using SSO disabled, fixed identity = Workspace Identity.
4. Report consumers need only Read on the semantic model, not the mirror.

Source: Direct Lake security integration · Service principals for Fabric · Workspace identity.

5. SharePoint, Fabric SQL Database, and DataFlow Gen2¶

SharePoint Shortcut + automatic DataFlow Gen2 / Pipeline trigger¶

Scenario. Files land in a Lakehouse via OneLake Shortcut to a SharePoint Document Library. Want: user uploads file → DataFlow processes it → output as clean CSV / XLSX returned to user.

OneLake events do NOT fire on shortcut targets. The OneLake event grid (Microsoft.Fabric.OneLake.FileCreated) only fires when files are written to OneLake-native storage (Files/Tables in a Lakehouse). Shortcuts are pointers — the file is still written to the SharePoint store, so no OneLake event is emitted.

Supported alternatives, in order of preference:

1. Power Automate SharePoint trigger → Fabric Pipeline REST API. "When a file is created (properties only)" SharePoint trigger → HTTP action calling POST /v1/workspaces/{ws}/items/{pipelineId}/jobs/instances?jobType=Pipeline with a file-path parameter. This is the canonical Microsoft pattern.
2. Scheduled Fabric Pipeline that scans the shortcut folder via Get Metadata → ForEach → parameterized Copy / Dataflow. Simplest fallback; latency = the schedule interval.
3. Activator + OneLake events is viable only if you first copy the file from the SharePoint shortcut into a native OneLake folder — which then emits FileCreated events.

For the self-service file processing pattern:

[User uploads file to SharePoint]
         │
         │  Power Automate SharePoint trigger
         ▼
[Power Automate flow]
         │
         │  HTTP POST → Fabric Pipeline REST API (runOnDemand)
         ▼
[Fabric Pipeline: Copy + Dataflow Gen2 transformation]
         │
         │  Output as CSV/XLSX
         ▼
[SharePoint Document Library or OneDrive — via SharePoint connector "Create file"]

Caveats:

• SharePoint triggers in Power Automate do not fire on subfolders — create multiple flows or use the parent library.
• Power Automate's per-flow license matters at volume (Pay-as-you-go vs per-user plans).

Source: OneLake events · Build event-driven data pipelines · SharePoint connector triggers in Power Automate · Fabric Pipeline REST API.

Fabric SQL Database — ingestion best practices¶

Fabric SQL Database (distinct from Fabric Data Warehouse) has a narrower ingestion surface than Azure SQL DB. Defaults:

• Connection: TDS over TCP port 1433 only. Open this on your gateway / firewall.
• Authentication: Microsoft Entra ID only — no SQL logins, no Windows auth. Use a service principal for automation.
• Recovery model: Full only. No minimal logging in bulk import.
• CDC: Not available — use Fabric Mirroring to OneLake instead (auto-enabled for Fabric SQL DB).
• Encryption: System-managed TDE only. Customer-managed keys (CMK) are not supported.

Recommended ingestion patterns:

Source: Fabric SQL Database limitations · Data virtualization in Fabric SQL Database (OPENROWSET).

Ingestion patterns that are NOT supported in Fabric SQL Database¶

For ODBC bulk-load drivers, the most common errors are caused by:

1. TDS version mismatch — Fabric SQL DB requires modern TDS (8.0+). Older drivers will negotiate down and fail. Update the driver to ODBC Driver 18 for SQL Server (17.x is too old for some scenarios).
2. Port 1433 blocked — verify outbound 1433 on the gateway / proxy / corporate firewall.
3. SQL login fallback — ODBC drivers default to SQL auth; force Authentication=ActiveDirectoryServicePrincipal or ActiveDirectoryInteractive in the connection string.

Source: Fabric SQL Database limitations · OPENROWSET BULK in Fabric SQL DB.

DataFlow Gen2 unable to select a Lakehouse destination when reading via Power BI gateway¶

This is a documented limitation, not a bug.

Root cause: DataFlow Gen2 staging uses TDS over TCP 1433 to read from its internal staging Lakehouse. On-prem gateways and corporate proxies frequently:

• Block outbound 1433 (only allow HTTPS/443).
• Only proxy generic HTTP/TLS (not TDS).

When a gateway-bound dataflow has multiple queries that reference each other, the second query can't read staged results from the staging Lakehouse over 1433 → WriteToDatabaseTableFrom_* error.

Additional constraints:

• Gateway version: minimum 3000.270 (May 2025) for incremental refresh
• Lakehouse destination; 3000.290+ for "Navigate using full hierarchy" schema support.
• Lakehouse destination does not support spaces or special characters in column / table names, and does not support Duration or Binary columns.

Documented workarounds (in order of robustness):

1. Open outbound TCP 1433 from the gateway server to Fabric SQL endpoints. The proxy must support TDS, not just HTTP.
2. Single-query design — write directly to Lakehouse, do not reference staged queries. Disable Fast Copy.
3. Stage to ADLS Gen2 first: a Fabric Pipeline Copy activity reads from the gateway → writes to ADLS Gen2, then a cloud-only DataFlow Gen2 or Pipeline loads ADLS Gen2 → Lakehouse. This is the most robust enterprise pattern when the gateway environment can't open TCP 1433.
4. Upgrade the gateway to at least 3000.270.

Source: Gateway considerations for DataFlow Gen2 destinations · DataFlow Gen2 limitations · DataFlow Gen2 incremental refresh limitations · Lakehouse connector for DataFlow Gen2.

📚 Related Documentation¶

• Mirroring — Fabric Mirroring end-to-end
• Direct Lake — connectivity, guardrails, fallback
• Network Security — VNet, private endpoints, managed VNet
• Fabric SQL Database — overview + best practices
• DataFlow Gen2 — destinations, refresh, gateway
• Identity & RBAC Patterns — workspace roles, item permissions, Entra ID groups
• Multi-Tenant Workspace Architecture — production vs UAT, cross-workspace patterns
• Outbound Access Protection — workspace egress controls

If you have a scenario not covered here, file an issue at fgarofalo56/Suppercharge_Microsoft_Fabric/issues and tag it field-question.