Fabric SQL Database names: Remove GUID suffix
When provisioning a new Fabric SQL Database, after typing in the name I want, what I get is that name PLUS some random GUID characters. This just seems wrong. Nobody likes to have their stuff renamed. As I understand it by someone from Microsoft in the Fabric Community, this was done to ensure a unique name across the entirety of Microsoft Fabric. It would be nice if that was NOT a requirement. Maybe you can make it like Fabric Warehouses where it is the combination of the Tenant, Workspace, and Data Warehouse name that needs to be unique.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.😊Support Japanese names in schema-enabled Lakehouses
Currently, Microsoft Fabric Lakehouses without schemas enabled can use Japanese workspace names and Japanese table names. However, I confirmed the following limitations in schema-enabled Lakehouses: ・A schema-enabled Lakehouse cannot be created if the workspace name contains Japanese characters ・Japanese table names cannot be used in a schema-enabled Lakehouse. I also confirmed with Microsoft Support that this is currently expected behavior. However, these limitations are not clearly documented in the official documentation. For users working in Japanese environments, it is difficult to know in advance that the supported naming rules are different depending on whether schemas are enabled or disabled. In addition, if Japanese names are already used in a Lakehouse without schemas enabled, errors may occur when migrating to a schema-enabled Lakehouse. This can affect migration planning and naming conventions. Therefore, I would like to request one of the following improvements: Allow Japanese workspace names, Lakehouse names, schema names, and table names in schema-enabled Lakehouses. If this cannot be supported, clearly document the unsupported characters and naming limitations in the official documentation. Using only English names is a possible workaround. However, users in Japan and other local language environments may use local language names to make tables and other resources easier to understand for business users. It would be helpful if schema-enabled Lakehouses supported Japanese names in the same way as Lakehouses without schemas enabled.
Support for Always Encrypted / Client-Side Column Encryption in Microsoft Fabric
We currently have two important use cases—one in the financial sector and another in healthcare—where administrators need to manage and operate the platform, but under no circumstances must they be able to read sensitive data. SQL Server already provides a proven solution for this scenario through Always Encrypted with client-side column encryption. This feature ensures that even database administrators cannot access the plaintext values of highly sensitive columns. For both use cases, support for a similar capability in Microsoft Fabric would be a key requirement for migration to the platform. In our scenarios: Sensitive data would remain encrypted at all times within Fabric. Administrators could manage workloads, operations, backups, and performance without being able to view the protected data. If encrypted tables appear in a mirrored database, it would be acceptable for the encrypted columns to remain unreadable. Alternatively, an option to exclude such tables from mirroring would also be a valid approach. This capability would significantly strengthen Fabric's position for regulated industries such as banking, insurance, healthcare, and public sector organizations where separation of duties and data confidentiality are mandatory requirements. Question to the community and product team: Are there plans to support a Fabric equivalent of SQL Server's Always Encrypted with client-side key management and column-level encryption?
Support advanced ODBC/IAM authentication parameters for Amazon Redshift and similar connectors
Power BI currently does not support passing advanced ODBC driver parameters in native connectors such as Amazon Redshift. Unlike other BI tools (e.g., Tableau), Power BI abstracts the connection layer and restricts authentication to predefined methods, which prevents usage of enterprise-standard authentication mechanisms. Specifically, Power BI does NOT allow configuring: IAM-based authentication (IAM=1) Custom authentication plugins (AuthType=Plugin) External Identity Provider (IdP) integration (e.g., Ping SSO) Role assumption using IAM roles (preferred_role) Advanced connection string parameters at driver level Custom proxy and federation parameters Working Scenario in Other Tools (Tableau Example) In Tableau Desktop, we are able to use advanced ODBC parameters such as: AuthType=Plugin; IAM=1; plugin_name=Ping; preferred_role=arn:aws:iam::<account-id>:role/<role-name>; idp_host=<idp_host>; idp_port=443; http.proxyHost=localhost; http.proxyPort=9000; ... This allows: AWS IAM role-based authentication Federated SSO using enterprise identity providers (Ping SAML) Dynamic role-based access control across environments (DEV/PPR/PRD) Standardized enterprise security model Business Requirement Our organization uses AWS-based data platforms (Redshift / Databricks) with: IAM role-based access control Federated authentication via Ping SSO Service accounts (SRV accounts) for BI tools We require Power BI to support: Secure IAM-based authentication Role assumption similar to Tableau Consistent enterprise authentication patterns across BI tools Microsoft Support has confirmed that: Current connectors are standard and do not allow adding custom parameters, and feature requests should be submitted via the Fabric Ideas portal. We request the product team to evaluate and prioritize support for advanced authentication and ODBC parameter configuration, as this is a critical requirement for enterprise adoption.Getting frequent error while selecting the data from warehouse tables and shortcut views in wh
Getting frequest error like "Invalid value" on multiple tables and shortcut views in warehouse and this is not consistent, same query will run after sometime. please let me know the solution because this is causing us the more failures in prod. Regards, Venkat
Power Query Relationship Manager for Joins, Appends, and Query Dependencies
Add a relationship manager inside Power Query for Power BI that visually manages joins, appends, merges, and query dependencies. Problem: In larger Power BI models, many important data connections are created inside Power Query through merges, appends, and referenced queries. These relationships are often harder to manage than model relationships because they are spread across individual query steps. This can make models more difficult to maintain, especially for areas like finance where data accuracy, traceability, and controlled transformations are critical. Proposed Solution: Create a Power Query Relationship Manager that allows report creators to: View all merges, appends, joins, references, and dependencies in one place. See which queries feed into other queries. Identify broken or risky query connections. Manage join types and append logic centrally. Document why specific joins or appends exist. Improve visibility over transformation logic before data reaches the model. Benefits: Reduces memory and refresh inefficiencies. Improves model stability. Makes finance and operational models easier to audit. Reduces reliance on complex front-end measures. Helps prevent model breakdowns caused by hidden query dependencies. Improves development speed for large Power BI models. Example: A finance model may use multiple source tables for accounts payable, accounts receivable, inventory, payroll, and general ledger data. Instead of tracking each merge or append inside separate query steps, the developer could open a Relationship Manager view and see how each query connects before the data is loaded into the model. Business Impact: This would make Power BI models easier to maintain, more reliable, and more scalable. It would be especially valuable for enterprise reporting, finance reporting, and large segmented models where many transformations happen before the data reaches the semantic model.
Add Dataverse as a Real-Time Data Source
Currently Dataverse is not available to use as a real-time data source. Adding Dataverse will allow dashboards for real-time views of Dataverse and other Power Platform data natively. Real-time dashboards previously supported dataverse data with power automate pushing to streaming datasets. This capability is now deprecated but not replaced.Enable Connection from Fabric Notebook to Fabric SQL Database
The core issue is the inability to directly access Microsoft Fabric SQL Databases from within Fabric Notebooks, despite the availability of JDBC and ODBC connection strings. The built-in notebook authentication token library appears to be missing Fabric SQL as an option. It does not currently appear possible (or at least not documented how) to access a Fabric SQL Server Database from within a Fabric Notebook. I see JDBC and ODBC connection strings, but these don't work apparently because the library to create authentication tokens is missing Fabric SQL as an option. Current Impact 1. Enterprises must create complex workarounds ("Rube Goldberg architectures") to establish basic data flows that leverage SQL Server 2. The platform fails to deliver on its "unified" promise, leading to a loss of faith in the Fabric brand 3. SQL Server's established strengths are not being leveraged effectively, further eroding trust that Fabric can deliver on enterprise data needs Summary This is a critical feature request that highlights a significant gap in Microsoft Fabric's platform integration. The inability to easily access Fabric SQL Databases from Fabric Notebooks undermines the platform's unified vision and creates unnecessary complexity for enterprise users. The request is well-justified, technically feasible, and would bring significant value to the platform.
Fabric Mirroring (and all artifacts) - Reassign owner
Probelm: I have users who have created Mirroring from Azure SQL DB's (although this problem exists with all mirroring) and if they dont log into fabric often the mirroring breaks. While best pratice, now, is to use a servce account when creating these types of artifacts. There isnt any warning when creating them and at this point the only way to correct is to recreate the artifact which breaks things attached to it. Suggest Solution: Please let me reassign all artifacts to a diffrent owner.
