Support User-Defined Data Types (UDTs) in SQL Server Mirroring for Microsoft Fabric
Description Currently, SQL Server mirroring in Microsoft Fabric does not support User-Defined Data Types (UDTs). This limitation blocks ingestion and mirroring scenarios for databases that rely on UDTs, even when those UDTs are simple aliases of fully supported native SQL Server data types. Business Impact We are working with a third-party vendor database where: The schema is not under our control UDTs are used extensively throughout the model These UDTs are aliases of standard SQL Server data types (e.g., VARCHAR, INT, etc.) Because of this limitation, we are unable to leverage Fabric mirroring for this data source without introducing complex and potentially fragile workarounds (e.g., schema replication, type conversion layers, or ETL pipelines). Rationale Under the hood, SQL Server alias UDTs map directly to base system types. From a data movement and storage perspective, these should be fully compatible with existing Fabric mirroring capabilities. Blocking on UDTs: Creates unnecessary friction for onboarding common enterprise systems Prevents adoption in scenarios involving vendor-managed schemas Requested Enhancement Enable support for User-Defined Data Types (UDTs) in SQL Server mirroring by: Automatically resolving alias UDTs to their underlying base data types during ingestion/mirroring or Providing a configuration option to map UDTs to their base types Expected Outcome Seamless mirroring of SQL Server databases that use alias UDTs Elimination of unnecessary preprocessing or schema transformation steps Broader adoption of Fabric mirroring in enterprise environments with vendor-controlled schemas Additional Notes This request specifically targets alias UDTs, not complex CLR-based types.
Notify Subscription Owners About Invalid Email Recipients in Power BI
Power BI should automatically notify subscription owners whenever one or more recipient email addresses are invalid or undeliverable. Currently, report subscriptions may silently fail for specific recipients without providing clear feedback to the person who created and manages the subscription. A notification should identify which email addresses could not receive the subscription and explain the reason, such as an invalid address, deleted user account, or external recipient restriction. This would allow subscription owners to quickly update the recipient list instead of assuming that reports are being delivered successfully. Providing proactive notifications for failed deliveries would improve reliability, reduce support requests, and ensure that important reports reach their intended audience. It would also enhance the overall user experience by making subscription management more transparent and easier to maintain.Microsoft Fabric Mirroring Native Multi-Source Consolidation into a Single Delta Table
Idea / Feature Request: Microsoft Fabric Mirroring is an excellent feature for near real-time operational replication into OneLake, especially for current-state analytics workloads. However, there is currently a major architectural limitation for many enterprise operational sync scenarios: One mirror per source. Today, each source database becomes its own separate mirrored database/table inside Fabric. Example: Store DB 1 → Mirrored Table 1 Store DB 2 → Mirrored Table 2 Store DB 3 → Mirrored Table 3 But many enterprise architectures require: Multiple source databases → One consolidated Delta table This is very common in: Retail store systems Franchise systems Multi-tenant applications Branch/store operational databases Distributed POS environments Regional operational systems My current use case: I currently ingest the same operational tables from multiple SQL Server store databases into one consolidated Delta table inside Microsoft Fabric Lakehouse. I achieve this today using only a single dynamic Fabric Copy Activity: → SQL Server Sources → Direct Delta Upsert → One Consolidated Delta Table No notebooks. No Spark jobs. No Parquet staging. No intermediate merge layer. No additional orchestration. The Copy Activity dynamically: loops through multiple source SQL databases reads similar source tables injects metadata columns dynamically upserts directly into one cumulative Delta table Example metadata columns: DW_LOCATION DW_SERVERNAME DW_SOURCE_SYSTEM DW_PACKAGE_NAME This architecture provides: very fast operational sync low latency minimal operational overhead simplified maintenance high-performance direct-to-Delta ingestion The problem with current Mirroring: If I move to Mirroring today, Fabric mirrors each source separately. That means I would still need: Notebook Pipeline Spark merge process Dataflow or another consolidation layer to merge all mirrored sources into a single final Delta table. This removes many of the operational and performance benefits for high-frequency sync workloads. Suggested Feature: It would be extremely valuable if Fabric Mirroring could support: Native Multi-Source → Single Delta Table Consolidation Possible configuration ideas: Multiple source databases mapped into one destination Delta table Automatic source metadata injection Source identifier columns Native merge handling Optional partitioning by source/store/location Dynamic schema alignment Incremental synchronization handling Why this would be very valuable: This would allow Fabric Mirroring to become a true enterprise operational consolidation engine for: high-frequency ingestion large-scale operational replication retail environments multi-store architectures distributed SQL systems multi-tenant operational analytics without requiring additional Spark/Notebook merge layers. This would significantly reduce: operational complexity compute overhead orchestration requirements maintenance effort end-to-end latency while still preserving Mirroring’s biggest strengths: near real-time replication CDC/change-based sync managed ingestion low source impact OneLake-native integration I believe this would be a very powerful enhancement for Microsoft Fabric enterprise architectures. Please vote if you find this feature valuable for enterprise operational sync and multi-source consolidation scenarios in Microsoft Fabric Mirroring.😊
Can we support Workspace ID authentication when using a gateway connection?
Currently, Workspace ID authentication is only available for cloud connections. We would like to request support for Workspace ID authentication when using gateway connections as well. <document :Authenticate with workspace identity> ---- ・You can create connections with workspace-identity-based authentication in the Manage Gateways and Connections experience for a cloud connection. ・Workspace-Identity-based authentication is currently not supported for gateway connections. ----Allow Sharepoint Library Metadata (List) Mirrored
When it comes to mirroring there is a gap when it comes to sharepoint Libraries. In the Main Interface it shows the library as a list, but it defaults to just creating a onelake shortcut to the files without the associated metadata. Metadata should also be mirrored or be an option to mirror than just sharepoint lists alone. Many Sharepoint Libaries are enriched with metadata that can be used for reporting or data transformation.
Enable Ownership Change / Take‑Over for Mirrored Database Items in Fabric
Mirrored DBs do not support ownership transfer today. This becomes an issue when someone leaves the company. And the user tied to the ownership is beeing disabled. That means you need to recreate the whole mirroring database and recreate all shortcuts, jobs pipelines etc etc.. Alot of work. The Take‑Over functionality exists for other Fabric items but excludes mirrored DBs. This is a critical operational need for enterprise workloads. Please consider developing this functionality.
