📉 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:Allow to use service principal for VNet data gateway connection to SQL Server
Service principal authentication is not supported for Azure SQL server connections when using an on-premises data gateway or a virtual network (VNet) data gateway. As a result we have to fallback to using less secure basic authentication with SQL user when we switch from Cloud connection to VNet gateway one. We would like to be able to continue to be using more secured access approach with service principal when we tighten the security by restricting access to DB. It would be also beneficial if Workspace identity mechanism is also supported (currently it is only available for Cloud connections).Show the workspace name for duplicate SQL endpoints with the same name in Desktop PowerBI
When multiple Fabric SQL endpoints have the same name, Power BI Desktop should display the source workspace name alongside the endpoint name during connection and in imported table metadata, so users can distinguish between dev, test and prod sources. Currently the only thing to determine in the report is connected to a dev, test or prod SQL endpoint is to look at the SQL endpoint ID which is still not clear and requires users to wither reconnect or open the workspace in the web and get the SQL endpoint ID that way.
:: operator for typecast in T-SQL
Introduce support for the ::type cast operator in Fabric Data Warehouse as syntactic sugar for the existing CAST(... AS type) expression. The new operator would be functionally equivalent and compile to the same internal representation, providing a more concise and familiar syntax for users coming from PostgreSQL, Snowflake, Databricks, and other modern SQL engines: Examples SELECT '123'::INT; SELECT order_date::DATE; SELECT total_amount::DECIMAL(10,2); Benefits Reduces verbosity for common type conversions. Improves developer productivity and query readability. Aligns Fabric DW with widely adopted SQL dialects that already support ::type. Low-risk addition because it is purely syntactic and can be translated internally to existing CAST semantics.
