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.   ... View more

The business needs Excel to perform on Fabric   The Problem: Unoptimized Capacity Consumption and Performance Bottlenecks While Excel's live connection to Fabric Semantic Models is a key feature, it currently presents a significant challenge for enterprise-level deployments, primarily related to performance and the unoptimized use of Fabric capacity. The core issue is that the current connection method, which relies on the XMLA endpoint and MDX query translation, leads to:  * Excessive Capacity Consumption: Every user interaction—from dragging a field to applying a filter—generates an independent, and often verbose, MDX query that is translated and executed. This constant, unoptimized querying on a per-user, per-click basis results in a high number of interactive queries, which are the most expensive type in Fabric capacity.  * Poor User Performance: As a result of the unoptimized queries, users experience frustratingly slow response times. A simple action that should be near-instantaneous can take several seconds to complete, especially with complex semantic models and multiple concurrent users. This degrades the user experience and can lead to a lack of trust in the centralized data model. The Proposed Enhancement: A Modern, Optimized Connection Layer We request the development of a new, modernized connection layer for Excel that is purpose-built for Fabric Semantic Models. This would move beyond the legacy MDX translation approach and provide a more intelligent and efficient way for Excel to interact with the service. Key features of this enhanced connection layer should include:  * Smart Query Batching: Implement a mechanism to intelligently batch multiple user actions into a single, optimized query to the Fabric service. This would significantly reduce the number of interactive queries, lowering capacity consumption and improving performance.  * Native DAX Support: Instead of translating MDX to DAX on the server, allow Excel to generate optimized DAX queries directly from the client. This would eliminate a performance bottleneck and ensure that the queries are written in a way that best leverages the semantic model's structure.  * Improved User Experience: A faster, more responsive connection would dramatically improve the user experience, encouraging broader adoption of Fabric as the go-to platform for data analysis in conjunction with Excel. Business Impact: Unlocking True Enterprise Scalability This enhancement is not just a "nice-to-have"; it is critical for unlocking the true enterprise scalability of Microsoft Fabric. A modern, performant connection between the world's most popular spreadsheet tool and Microsoft's unified data platform would:  * Reduce TCO: By consuming capacity more efficiently, organizations can get more value from their Fabric investment and manage costs more effectively.  * Boost Productivity & Trust: Faster performance means business users can work more efficiently, building trust in the centralized data model and reducing reliance on manual, ad-hoc data sources.  * Strengthen the Microsoft Ecosystem: This would further cement the powerful synergy between Fabric and Office, demonstrating a seamless and high-performance experience for the millions of users who rely on both products daily. Summary: Everyone agrees, Excel is not going away. Optimizing Excel's connectivity to Fabric Semantic Models for capacity and performance is essential. We urge the Fabric team to prioritize the development of a modern, efficient connection layer that will not only solve current user frustrations but also enable organizations to confidently scale their analytics solutions. Fabric has gone miles beyond a reporting tool as it has evolved into Fabric, these changes fully fit within the scope of providing a robust end to end Analytics platform.     ... View more

With the rising adoption of Multi-Factor Authentication (MFA) across our organization and industry best practices, we are seeking a more robust and streamlined authentication method for connecting Power BI to Snowflake. Currently, Power BI primarily relies on username/password or OAuth 2.0 via Microsoft Entra ID. While these methods are functional, they can become cumbersome and less secure in MFA-enabled environments. We propose the implementation of RSA key pair authentication for Snowflake connections within Power BI. ... View more

Hello, Currently, Power BI connects to Google Cloud Storage using HMAC credentials, which require manual key management and pose security and scalability challenges. I propose adding support for Workload Identity Federation (WIF) as an authentication method to enhance security, simplify credential management, and align with modern cloud identity practices. Advantages of WIF Authentication Improved Security: WIF eliminates the need for long-lived HMAC keys by using short-lived, automatically rotated tokens via identity providers. No Key Rotation Hassles: Credentials are federated dynamically, removing the need to manually rotate or store HMAC keys. Centralized Identity Management: Integrates with enterprise identity providers, enabling fine-grained access control and auditability. Scalability: Ideal for large-scale deployments where managing static keys becomes impractical. Compliance-Friendly: Supports modern security standards and helps meet compliance requirements for cloud-native environments. Limitations of HMAC Authentication Manual Key Management: Requires storing and rotating static access keys, which increases operational overhead. Security Risks: Static keys are vulnerable to leakage and misuse if not handled securely. Limited Integration: Does not integrate well with identity providers or support federated access models. Audit Complexity: Tracking access and usage is harder compared to federated identity systems. Conclusion Adding WIF support for Google Cloud Storage in Power BI would significantly improve security, reduce administrative burden, and align with best practices for cloud identity management. This enhancement would benefit organizations looking to modernize their data access architecture while maintaining robust governance.   Thanks, Surendhar ... View more

Dataflows need a way to reference a table as input, do a comparison and perform upserts on through the data destination in a single dataflow. Instead of having to rely on truncate/reload with replace or creating a stored procedure to do upserts on a staged table of changes. ... View more

Currently complext type (json, struct) are supported in Onelake endpoint but not in SQL endpoint which prevents these important payload data types to be explored or used in Power BI. In big data world such fields are very common as many data generated through IoT are partially parsed in individual columns and raw json payload is left for future use or as on need basis. Before parquet - we use to store them as MapType which make them easy to further use. Adding this feature will do both - parsing those field easy for end user and also migration of existing data possible. ... View more

Overtime queries ran on a sql end point in a lake house build up in the my queries folder. They have to be individually deleted which can take a lot of time. There should be a way to delete all or highlight an delete multiple queries  ... View more

Could Microsoft support SQLMesh project so that they provide good compatibility against Fabric warehouse and lakehouse (via Spark)? Could SqlMesh be added as Fabric native workload to get it as service since this kind of sql modeling functionality with web UI is missing? Add support for Microsoft Fabric · Issue #3374 · TobikoData/sqlmesh ... View more

Based on https://community.fabric.microsoft.com/t5/Data-Engineering/Creating-a-Primary-Key-for-Lakehouse-Table/m-p/4742452#M10401 and based on error message that I'm receiving when creating keys from notebook (Table constraints (Primary and Foreign key) are not supported in V2 Datasource tables) seems that primary and foreign keys are not supported in Lakehouse. I believe that support for keys would be very useful and beneficial. The thing is that through the SQL analytics endpoint you can create them which is confusing so I contacted Microsoft to see what is the status and the response was: You're absolutely right—Microsoft Fabric currently has limited support for table constraints like primary and foreign keys. Here’s a summary of the current behavior and limitations: What Works: Primary keys can be defined only via the SQL Analytics Endpoint, using syntax like: ALTER TABLE MyTable ADD CONSTRAINT PK_MyTable PRIMARY KEY NONCLUSTERED (id) NOT ENFORCED; This allows you to register metadata constraints, which can be useful for documentation or downstream tools. Where Primary Keys Are Supported: Fabric SQL Database (distinct from Lakehouse) does support primary keys and foreign keys, similar to Azure SQL Database or SQL Server. However, even in Warehouse or SQL Analytics Endpoint, constraints like PRIMARY KEY, FOREIGN KEY, and UNIQUE are only supported when: NONCLUSTERED NOT ENFORCED Limitations: These constraints are not enforced—they do not prevent duplicates or ensure referential integrity. They are not supported in V2 Datasource tables, which is why attempts from notebooks result in the error: "Table constraints (Primary and Foreign key) are not supported in V2 Datasource table." Foreign keys and unique constraints follow the same pattern: metadata-only, not enforced. Known Issues Duplicate data can still be inserted, even if a primary key is defined. No enforcement during ingestion or transformation—you’ll need to handle integrity checks manually. Metadata APIs may not behave as expected (e.g., JDBC metadata queries may not return constraint info reliably). Microsoft has not officially announced full support for enforced constraints in Lakehouse tables. ... View more

I’m aware that Lakehouse Git integration in Microsoft Fabric is currently in preview. However, I believe some critical support is missing that would significantly enhance the usability and maturity of this feature.   At the moment, Git integration does not support versioning or tracking of critical Lakehouse objects such as: Tables Views User-defined functions Stored procedures These objects are essential components of any data platform, and not being able to track their definitions in source control limits our ability to: Perform proper code reviews Roll back changes Maintain consistent environments across workspaces Collaborate effectively in larger teams Follow DevSecOps best practices Suggestion: Please extend Git integration in Fabric Lakehouses to include full support for these objects. For example, warehouse git integration supports all of those objects. This enhancement would greatly improve DevOps practices in Fabric and align with modern data engineering workflows. ... View more

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. ... View more

When doing restore we always get a new database ID, Physical Name and SqlEndPoint, even if the database logical name is the same (eg restore over the top). This causes a massive increase in RTO as afer the restore all end points broke and configuration management had to be updated and re-tested. When doing a restore we need to have the ability to keep database exactly as it was, rather than always creating a clone. In a recent DR event it was 5 minutes to restore, but the 2 days before we stopped getting issues on end points and config change impact. ... View more

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. ... View more

We are working on a migration project to Fabric and need to combine data from inside a SQL Database with data in a Lakehouse then write it to another table in the database. Due to T-SQL compatibility issue with Data Warehouse, we want to use a Fabric SQL database for the Gold layer. For example: SELECT * FROM SilverLakehouseDeltaTable x JOIN GoldDatabaseSQLTable y ON y.id = x.id   This should be part of a INSERT / UPDATE or MERGE such as:   INSERT INTO AnotherGoldDatabaseSQLTable (Columns) SELECT * FROM SilverLakehouseDeltaTable x JOIN GoldDatabaseSQLTable y ON y.id = x.id The ability to read data from OneLake in a Fabric SQL database would solve this problem. ... View more

It should be possible to query data in a Fabric Lakehouse directly in Fabric SQL database using T-SQL. For example I have the following scenario where I want to join data from a table in my Fabric SQL DB to a delta table in my lakehouse then insert the resultset into another table in my Azure SQL database: INSERT INTO AnotherGoldDatabaseSQLTable (Columns) SELECT * FROM SilverLakehouseDeltaTable x JOIN GoldDatabaseSQLTable y ON y.id = x.id This isn't currently possible with Fabric SQL Database. ... View more

It would be great if there were a possibility to call a SQL Database stored procedures directly from a Data Warehouse stored procedures. A use case for this would be e.g. logging activities and events during ETL loads. ... View more

Within Fabric SQL databases you can cross-database query in the warehouse connection. However cross-database querying from one live SQL database to another is not possible. It would be great to have this possibility with 3-part names: select* from [sqldatabase].[dbo].[table_A]  By getting this migrating from on-prem SQL server or an Azure managed instance to Fabric will be easier. ... View more

Currently, databases are randomly assigned to a pool of logical servers and there is not a way to group databases under same logical server name. Please allow us to see all the SQL databases listed under the same logical server name. It would be ideal to create one connection to the server name. This eventually would make cross-database querying on the same server possible as well . ... View more