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.
Environment Copy/Duplicate
Why is there still no single tool to copy/duplicate an environment. Its seems that an MCP nor Deployment Pipelines can do all the necessary tasks to copy the whole of an env in its entirety, ie all artefacts and warehouses/lakehouses etc such for either 1) creation of a new environment like Pre Prod, Staging or to quickly replicate an environment. I know that using a combo of tools it can be done. But surely Fabric has matured enough for this to be available by now or have i missed something ?
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.
Keep Fabric SQL Endpoint Up to Date
When data is updated in a Fabric Data Warehouse or Lakehouse, it's not always up to date immediately when querying the SQL Endpoint. The same thing happens in a Fabric SQL Database but this is even more noticeable - on the SQL Database object, the data is always up to date, but on the SQL Endpoint object of the same database, the data can lag. It is possible to refresh this as part of a pipeline by including the refresh SQL endpoint activity, but in my view the data should always be up to date through the endpoint as this can lead to discrepancies.
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.
Cannot configure writeback for plan with guest account
It seems like it's not possible to configure writeback for a plan with a guest account. Please fix this as we use guest account to work in customer environments to avoid purchase of additional Power BI Pro licenses. Activity ID 8d5c3527-faea-4b7d-95b7-f7e6f10c819a Request ID f5d32f7e-b69d-454d-8531-818f3f165c18 Error Time Fri Jul 31 2026 16:17:28 GMT+0200 (Central European Summer Time) Service version 13.0.28509.443 Client version 2607.1.30035-train Cluster URI https://wabi-west-europe-redirect.analysis.windows.net/ Stack Trace Failed to fetch SQL credentials (status 500). 'tid' claim in the token does not match the tenant ID in the request header.
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?
