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.Allow Non-Breaking Schema Changes in Fabric CI/CD Deployments for Data Warehouse Objects
Hi, currently, Microsoft Fabric deployment pipelines can fail when a Data Warehouse deployment contains schema changes such as adding, removing, renaming, or modifying columns in existing tables. In environments where Data Warehouse tables already exist and CI/CD pipelines are used to automatically promote changes across Development, Test, and Production, this limitation becomes very important. For example, deployments can fail with errors similar to: DataLoss: The column is being dropped, data loss could occur. or ALTER COLUMN operation is not supported and deployment is blocked. As a result, even legitimate schema evolution scenarios require manual intervention, preventing fully automated deployments and increasing operational risk. Requested Improvement Provide configurable deployment options for Data Warehouse schema changes, such as: Allow schema evolution during CI/CD deployments. Support automatic handling of column additions, removals, and data type changes when explicitly approved. Introduce deployment settings to ignore or accept "data loss" warnings. Provide deployment modes similar to DACPAC publishing options available in SQL Server tooling. Offer pre-deployment validation and impact analysis without completely blocking the release. Business Impact This limitation significantly reduces the effectiveness of Fabric CI/CD pipelines for enterprise environments, where schema changes are a normal part of application and data platform lifecycle management. Without support for controlled schema evolution: Automated releases become unreliable. Manual production interventions are required. DevOps adoption is slowed down. Development, Test, and Production environments can become inconsistent. Supporting controlled schema changes would greatly improve Fabric's enterprise readiness and align deployment capabilities with modern DataOps and DevOps practices. Schema evolution should not require manual intervention in enterprise CI/CD deployment pipelines. Thank you for your support. I sincerely hope this limitation can be addressed, as it represents a significant challenge for organizations implementing automated CI/CD deployment processes with Microsoft Fabric.Allow Non-Breaking Schema Changes in Fabric CI/CD Deployments for Data Warehouse Objects
Hi, currently, Microsoft Fabric deployment pipelines can fail when a Data Warehouse deployment contains schema changes such as adding, removing, renaming, or modifying columns in existing tables. In environments where Data Warehouse tables already exist and CI/CD pipelines are used to automatically promote changes across Development, Test, and Production, this limitation becomes very important. For example, deployments can fail with errors similar to: DataLoss: The column is being dropped, data loss could occur. or ALTER COLUMN operation is not supported and deployment is blocked. As a result, even legitimate schema evolution scenarios require manual intervention, preventing fully automated deployments and increasing operational risk. Requested Improvement Provide configurable deployment options for Data Warehouse schema changes, such as: Allow schema evolution during CI/CD deployments. Support automatic handling of column additions, removals, and data type changes when explicitly approved. Introduce deployment settings to ignore or accept "data loss" warnings. Provide deployment modes similar to DACPAC publishing options available in SQL Server tooling. Offer pre-deployment validation and impact analysis without completely blocking the release. Business Impact This limitation significantly reduces the effectiveness of Fabric CI/CD pipelines for enterprise environments, where schema changes are a normal part of application and data platform lifecycle management. Without support for controlled schema evolution: Automated releases become unreliable. Manual production interventions are required. DevOps adoption is slowed down. Development, Test, and Production environments can become inconsistent. Supporting controlled schema changes would greatly improve Fabric's enterprise readiness and align deployment capabilities with modern DataOps and DevOps practices. Schema evolution should not require manual intervention in enterprise CI/CD deployment pipelines!! Thank you for your support. I sincerely hope this limitation can be addressed, as it represents a significant challenge for organizations implementing automated CI/CD deployment processes with Microsoft Fabric.Add Automatic Query Plan Regression Detection to Fabric Data Warehouse
Fabric Data Warehouse is adding richer graphical query plans and AI-assisted performance diagnostics. A common production problem is identifying when a previously healthy query becomes expensive after a deployment, schema change, statistics change, or significant data growth. Please add automatic query plan regression detection to Fabric Data Warehouse. Fabric should maintain a performance baseline for frequently executed queries and compare new executions against previous healthy plans. The comparison should identify major changes in joins, scans, data movement, cardinality estimates, memory requirements, execution duration, and resource consumption. When a regression is detected, Warehouse Monitor should show the previous and current plans side by side and highlight the operators responsible for the change. Administrators should also be able to configure regression thresholds and receive alerts when a critical production query exceeds its normal performance range. This would help teams detect query regressions before they become user-facing performance incidents.
Support Cloud Connections and Desktop Access to Warehouses in Inbound-Restricted Workspaces
Many organizations secure Fabric Warehouses with workspace-level private links and restrict inbound access ("Allow connections from selected networks and workspace level private links"), while keeping Power BI reports and semantic models in a separate open workspace. In our scenario, the Warehouse is in the restricted workspace and the semantic model is in an open workspace in the same tenant. Today, the open workspace can reach the restricted Warehouse only through a VNet Data Gateway or an On-premises Data Gateway, using the SQL Server connector. Two other common paths fail: Creating a Cloud Connection to the Warehouse SQL endpoint fails with an "Invalid connection credentials" message (HTTP 400). The credentials are valid. The same endpoint works from SSMS, an On-premises Data Gateway and a VNet Data Gateway, and the Cloud Connection succeeds once the inbound restriction is relaxed. Selecting the Warehouse in Power BI Desktop (OneLake catalog) fails with "Failed to get datamart schema" (HTTP 403). The credentials message is misleading, because the real cause is the workspace network restriction. This led to extra troubleshooting of permissions and credentials. Requested Enhancement: Please improve support for inbound-restricted workspaces so that administrators and report authors can: Create and use Cloud Connections to Warehouses and SQL analytics endpoints in restricted workspaces, for example through a trusted-service mechanism for the Power BI service, without removing the workspace's inbound protection. Browse and select Warehouses and Lakehouses in restricted workspaces from Power BI Desktop (OneLake catalog), instead of switching to the SQL Server connector and typing the endpoint manually. See error messages that name the workspace network restriction as the cause, instead of "Invalid connection credentials" or "Failed to get datamart schema". Find documentation that states which connection types (Cloud Connection, VNet gateway, On-premises gateway) are supported for cross-workspace access to restricted workspaces. This would reduce setup and troubleshooting time for secure Fabric deployments, remove the need to relax security settings just to use Cloud Connections, and give users the same experience in open and restricted workspaces.Support Cloud Connections and Desktop Access to Warehouses in Inbound-Restricted Workspaces
Many organizations use workspace-level private links with inbound access restricted ("Allow connections from selected networks and workspace level private links") to secure Fabric Warehouses, while keeping Power BI reports and semantic models in a separate open workspace. In our scenario, the Warehouse sits in a restricted workspace and the semantic model sits in an open workspace in the same tenant. "Figure 1: Inbound networking setting on the Warehouse workspace". That helps readers and any Microsoft reviewer. Currently, connecting from the open workspace to the restricted Warehouse works only through a VNet Data Gateway or an On-premises Data Gateway, and only after the data source has been created through the SQL Server connector. Two common paths fail: Creating a Cloud Connection to the Warehouse SQL endpoint fails with "Unable to create connection for the following reason: Invalid connection credentials" (HTTP 400). The credentials are valid: the same endpoint can be reached through SSMS, an On-premises Data Gateway and a VNet Data Gateway, and the Cloud Connection succeeds when the inbound restriction is relaxed. Selecting the Warehouse in Power BI Desktop (OneLake catalog / Warehouse picker) fails with "Failed to get datamart schema" (HTTP 403, with an inner 500 Internal Server Error). The "Invalid connection credentials" message is misleading because the real cause is the workspace network restriction. This led to time-consuming troubleshooting of credentials and permissions. Requested Enhancement: Please improve support for restricted workspaces so that administrators and report authors can: Create and use Cloud Connections to Warehouses and SQL analytics endpoints in inbound-restricted workspaces, for example through a trusted-service or allow-list mechanism for the Power BI service, without removing the workspace's inbound protection. Browse and select Warehouses and Lakehouses in inbound-restricted workspaces from Power BI Desktop (OneLake catalog), so authors don't have to switch to the SQL Server connector and manual endpoint entry. See clear error messages that state the workspace network restriction as the cause, instead of "Invalid connection credentials" or "Failed to get datamart schema". Find an explicit statement in the documentation of which connection types (Cloud Connection, VNet gateway, On-premises gateway) are supported for cross-workspace access to restricted workspaces. This would reduce the setup effort and troubleshooting time for secure Fabric deployments, remove the need to relax security settings just to use Cloud Connections, and give users a consistent experience between open and restricted workspaces.
Set SQL analytics endpoint access mode (User's identity) via REST API and Terraform
The SQL analytics endpoint enforces OneLake security only in User's identity access mode. The only documented way to choose the mode is the Security tab in the portal (Data access mode settings). Nothing in the Fabric REST API, the Fabric CLI or the Terraform microsoft/fabric provider can read or set it. The sqlEndpoints API covers list, connectionString, refreshMetadata and the sqlAudit settings only, and the Terraform provider has no SQL endpoint resource. Why it matters: we provision a workspace and lakehouse per customer with a service principal. We can create the lakehouse and its OneLake security roles through REST (dataAccessRoles), but the SQL endpoint does not enforce those roles until someone switches the mode in the portal, for every lakehouse. Data agents with lakehouse sources query through the SQL endpoint too. In our test on 2026-10-03 the endpoint stayed in delegated mode, so a row-restricted service principal read every row, both through the SQL endpoint and through a lakehouse data agent. The default is also unclear. The OneLake security GA announcement (May 2026) says User's identity mode is the default for new endpoints, but the documentation says new endpoints start in delegated mode, which matches what we saw. Request: 1. A setting on the SQL endpoint to read and set the access mode, for example GET and PATCH /v1/workspaces/{workspaceId}/sqlEndpoints/{sqlEndpointId}/settings/accessMode, like the existing sqlAudit settings. 2. An optional property in the Create Lakehouse creationPayload, so that a new endpoint starts in User's identity mode. Switching later makes every SQL endpoint in the workspace briefly unavailable and cancels running queries, so setting it at creation avoids that. 3. Support for service principals and managed identities, and a matching attribute in the Terraform provider (for example on fabric_lakehouse). This differs from the dataAccessRoles API, which manages roles but not the mode, and from the item identity API (identities/default/assign), which changes the identity used by delegated mode but does not switch the mode.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.
Improve the error messages on warehouse deployment failures
When a warehouse fails to deploy in the deployment pipeline currently we get a wall of text as an error message. Something like Backend Error import fail Exception Error occurred SQL Project build failure stored procedure A contains an unresolved reference Table1.Column1 Table2.Column1 SQL Project build failure stored procedure A contains an unresolved reference Table1.Column2 Table2.Column2 SQL Project build failure stored procedure A contains an unresolved reference Table1.Column3 Table2.Column3SQL Project build failure stored procedure B contains an unresolved reference Table1.Column1 Table2.Column1 SQL Project build failure stored procedure B contains an unresolved reference Table1.Column2 Table2.Column2 SQL Project build failure stored procedure B contains an unresolved reference Table1.Column3 Table2.Column3 etc. It would be much better if these failures were grouped by the item they are related to and we could expand for further details. E.g. stored procedure A - 3 failures - expand for more details stored procedure B - 3 failures - expand for more details This would make it much easier to review and resolve these errors. It would also be great if you can make the error window wider as at the moment it is quite narrow which leads to a lot of scrolling.
