File level commit - Need the ability to edit the commit description
I tried the recently announce file level commit for Fabric items. One notable issue I have with the feature (testing this with a Fabric warehouse, I'm assuming this would hold true for other items): While I am able to pick files to commit to source control, I am unable to edit the commit description. The current commit has a generic message "Committing 1 item from workspace <workspace_guid>". To best make use of this feature, it would be helpful to be able to edit the commit description so I can clarify what is in the commit.
Allow Workspace Identities as an authentication method for Fabric SQL Databases
Currently the only method of authentication in Fabric pipeline connections to Fabric SQL databases is using OAUTH2, meaning that the credentials of a specific user need to be used (with all the attendant issues around user/credential expiry). By allowing the option of workspace identity for authentication, no user creds would be needed. Obviously correct access controls would need to be defined, but that's standard SQL Server maintenance.File Level Deployment (especially Warehouse and Fabric SQL) for Fabric Deployment Pipelines
Fabric deployment pipelines currently support deploying items in their entirety. The announcements from Barcelona introduced file-level commit for Git, supporting more granular controls for source control of larger items like warehouses and databases. For organizations that want simpler approaches to CI/CD, it would be helpful to have file-level deployment as an option. For SQL-based items like warehouses and databases, it would be similar to the Schema Compare capabilities in Visual Studio, where you can pick specific objects in the item, identify dependencies, and have a publish script to review detailing how the deployment will be done.📉 How Would You Investigate a 20% Drop in Revenue?
A data analyst shouldn’t stop at identifying what happened. The real questions are: Where did the decline occur? → Why did it happen? → What caused it? → What should we do next? By analyzing regions, products, customers, time periods, and key business metrics, raw data can reveal the root cause behind the numbers. Good data analysis turns numbers into decisions. 📊 #DataAnalysis #BusinessIntelligence #PowerBI #MicrosoftFabric #DataAnalytics
Auto-generate INSERT VALUES scripts for configuration data migration across environments
Hi Fabric Team, I would like to suggest a feature that could significantly simplify deployment and environment promotion activities. Today, when configuration tables contain reference or application settings data (for example mappings, parameters, business rules, or integration configurations), moving these records from a Development environment to Test or Production often requires manually creating INSERT INTO ... VALUES scripts. It would be extremely useful to have a built-in capability in Fabric that allows users to select records from a table and automatically generate the corresponding INSERT statements. I believe this capability would be particularly valuable for teams using Fabric to manage configuration-driven solutions where tables contain metadata and application settings that must remain synchronized across environments. Thank you for considering this idea.
Support Outbound Mirroring from Fabric Warehouse to External SQL Server
HI Team I would like to propose a feature request for Microsoft Fabric: Outbound Mirroring (Reverse Mirroring) from a Fabric Warehouse to external targets, specifically SQL Server. Currently, Fabric Mirroring is a fantastic inbound feature that replicates data from external sources (like SQL Server, Azure SQL, and Snowflake) into OneLake. However, there is no native, low-latency way to mirror data out of a Fabric Warehouse back into an operational SQL Server instance. Why this is needed: While Fabric excels as a centralized analytical lakehouse, many organizations still rely on traditional SQL Server databases to power operational systems, legacy applications, and real-time transactional workflows. When analytical insights or aggregated data are generated inside a Fabric Warehouse, getting that data back into an operational SQL Server requires building and maintaining manual Data Factory pipelines, Dataflows, or custom PySpark notebooks. Proposed Solution: Introduce an outbound mirroring capability. This would allow users to select a Fabric Warehouse table (or view) and automatically stream or replicate changes down to a designated on-premises or cloud-based SQL Server instance with minimal configuration and latency. I believe this would bridge the gap between operational databases and Fabric's analytical environment, making Fabric an even more flexible centerpiece for hybrid data architectures. I would love to hear thoughts from the community or if others face similar architecture challenges!
Fabric Copy Jobs desperately need basic editability after creation.
Requiring users to recreate an entire Copy Job just to change something as fundamental as the source connection or connection URL is unnecessarily restrictive and creates significant maintenance overhead. A Copy Job should allow users to: Change the source connection Change the destination connection Edit connection details Repoint a job to a replacement connection Preserve existing mappings, scheduling, and other configuration when changing connections Having to rebuild a working job because one connection property needs to change makes Copy Jobs much less useful for production data workflows. Please add the ability to edit or replace connections on an existing Copy Job.Bring back native SQL statements for Snowflake connections in Power BI Desktop
Description: Until recently, Power BI Desktop allowed users to provide a native SQL statement directly when creating a connection to Snowflake. Although this option was not available through the connection dialog in Power BI Service or Power BI Report Builder, there was a practical workaround: create the Snowflake query in Power BI Desktop and then reuse the generated Power Query code in Power BI Service or Report Builder. This worked perfectly. After my organization deployed Power BI Desktop version 2.158.1177.0 64-bit (September 2026), I was surprised to find that this option is no longer available. As a result, users who want to execute a specific SQL statement against Snowflake are now effectively pushed towards working with M code in the Advanced Editor. For users and organizations where Snowflake and SQL are central to the data platform, this feels like a significant step backwards. SQL is often the natural and preferred language for querying Snowflake, while M should not have to become the interface simply because the native SQL option has disappeared. Suggestion: Please restore the ability to provide a native SQL statement when creating a Snowflake connection, and ideally make this capability consistently available across: Power BI Desktop Power BI Service Power BI Report Builder This would provide a much more consistent experience and give users the freedom to use SQL where SQL is the most appropriate tool. I cannot imagine that forcing Snowflake users towards M for this scenario is the intended end state, so I hope this is something Microsoft will reconsider. If you work with Snowflake and recognize this limitation, please vote for this idea. Before: After:
