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

This feels like a genuine design bug related to how Fabric and Power BI fit together. I'm working in a workspace backed by an F64 Fabric capacity. Using the same user account (Fabric Free), I can edit and refresh semantic models just fine through notebooks, pipelines, the Fabric CLI, and Git integration (PBIP/TMDL). All of those are documented Fabric paths, and they work as expected. If I try to do the same thing from the Power BI Service UI (for example, manually refreshing the semantic model) I get hit with an "Upgrade to a paid Power BI license" message. Same model, same workspace, same capacity, same user, different outcome. The only difference is whether I clicked a button in the UI or initiated the action through a Fabric surface. The issue is about inconsistent enforcement of the same capability. Whether an operation is allowed shouldn't depend on whether it's triggered via the UI versus Fabric orchestration. That makes behavior feel non‑deterministic and forces operators to avoid the UI entirely for tasks that are otherwise allowed and already running on paid capacity. It also creates artificial licensing pressure. The capacity is paid for, the operation is supported and allowed via multiple paths, but you still need Pro just to press the UI button. That's hard to justify, and it actively worsens governance and operability. There are already community threads where people hit parts of this problem (for example, being blocked from UI refresh with Fabric Free licenses on capacity), but none really address the bigger issue: Fabric allows the operation everywhere except the Power BI UI. At minimum, this should be reconciled. Either the UI entitlement checks should align with what Fabric already allows, or there should be a clear, capacity‑scoped "operator" capability for management of Power BI items. Even clear in‑product guidance explaining why automation is allowed but UI actions are blocked would be better than the current experience. Right now it just feels fragmented. Fabric presents itself as a unified, capacity‑first platform, but the Power BI UI still behaves as if it's living under a separate, legacy licensing model. ... View more

Dataverse Virtual Tables currently do not support File, Attachment, or Image data types. When binary content (for example images, videos, ZIP files, or documents) is exposed from external sources such as Microsoft Fabric Lakehouse, Azure Blob Storage, or SQL, Dataverse treats the data as text and applies strict character-size limits. This results in truncated Base64 content and prevents proper rendering or access to the original files.   Solution: Allow virtual tables to reference externally stored binary data via streaming Enable secure rendering or download via Dataverse  This enhancement would allow customers to: Keep binary data in Fabric or Blob Storage Render images and access files directly in Dataverse apps Avoid duplication, reduce storage costs, and simplify architecture ... View more

Power BI treats text values in the semantic model (VertiPaq / DAX engine) as case‑insensitive. While Power Query (M) is case‑sensitive, once data is loaded into the model: ... View more

Please allow more than the max of 20 bookmarks. ... View more

On the Microsoft 365 Usage Analytics Template app, on the Activation/Licensing page there is a table at the bottom called "Users Assigned a Subscription" There used to be columns to the right of Assigned count, which brokedown the Assigned count per month.     This is a request to reinstate these columns.   ... View more

When using Dataflow Gen2 in Microsoft Fabric, parameters behave differently depending on how the Dataflow is executed, even when the same parameters and values are used. After detailed investigation and confirmation with Microsoft Support, we observed the following inconsistent behavior: Direct Dataflow execution (via Dataflow UI): When a query or query-related logic is passed as a Dataflow parameter, the Dataflow correctly re-evaluates the query and adapts the schema accordingly. Pipeline-triggered Dataflow execution: When the same parameter is passed from a Pipeline to the Dataflow, the schema is not re-evaluated or adapted, even though the parameter values are identical. Internally, the Pipeline appears to execute the Dataflow using a different execution path / mashup handling mechanism than a direct Dataflow run. This leads to schema mismatches, mashup document errors, or an inability to support dynamic query logic when triggered via a Pipeline.   Why This Is a Problem From a user perspective, Dataflow parameters should behave consistently, regardless of whether the Dataflow is executed directly or via a Pipeline. Currently, solutions that work perfectly in a direct Dataflow run break when orchestrated via Pipelines, even though Pipelines are the recommended orchestration mechanism in Fabric. This limits the ability to build generic, parameter-driven Dataflows that are orchestrated by Pipelines. It also creates confusion, as there is no clear documentation explaining that schema changes are only supported in direct Dataflow runs but not in Pipeline-triggered runs. Expected Behavior Parameter handling and schema evaluation should be harmonized between: Direct Dataflow Gen2 runs Pipeline-triggered Dataflow Gen2 runs If a Dataflow supports schema adaptation based on parameters, this behavior should be identical regardless of the execution method. Alternatively, if there are technical limitations, these should be explicitly documented, including guidance on supported design patterns. ... View more

For debugging and testing pipeline activities during development, allow us to select one or multiple activities and run only the selected pipeline activities.   For example, I'm working on editing a Notebook, and now I want to run the pipeline with that Notebook, but I don't want to run all the activities in the pipeline because that is time consuming.   I'm aware of the Deactivate activity option that already exists, but that requires Editing and Saving the pipeline as well. Instead, I just want to select which activities to run interactively by highlighting those activities and click Run, without needing to Edit/Save the pipeline.   An option to 'Run from selected activities' would also be great - select one or more activities, and run the selected activities and all subsequent activities. ... View more

Hi,   We currently have a lot of dataflows gen1. We use 3 environments in our deployment pipelines (DEV - TST - PRD). Our company is investigating to upgrade our dataflows from gen1 to gen2.   However, we noticed we cannot use the deployment rules on dataflows gen2. Can you please fix this, or at least tell us how we can use dataflows gen2 such that the parameters are automatically adjusted on the TST and PRD environment like we have now for dataflows of gen1. We dont want to copy dataflows gen 2 to TST and PRD and manually adjust the parameters there, because it feels very stupid and we have a greater risk that somebody forgets and dataflows update with the wrong info from the wrong environment (or don't update at all) overnight. ... View more

While it is possible to configure visuals for line charts and clustered column charts, there is currently no option to customize visual settings (such as bar thickness) for each legend value in a clustered column chart. We would like to request the ability to adjust bar thickness individually for each legend category.    For reference, this level of visual customization can be achieved in other BI tools such as Tableau, where users can control bar appearance at a more granular (each legend category) level. ... View more

Enable filtering capabilities in Lineage View (similar to Workspace List View) so that users can apply the same filters and view a consistent, scoped representation of workspace items and their dependencies. This would improve usability and alignment between the two workspace browsing experiences. ... View more

Issue:   Error refreshing the Dataflow Gen2 with multiple Lakehouse Schemas selected as the data destination: WriteToDataDestination: There was a problem refreshing the dataflow: "Couldn't refresh the entity because of an issue with the mashup document. MashupException.Error: Expression.Error: We cannot convert the value null to type Table. Details: Reason = Expression.Error; ErrorCode = 10277; Microsoft.Data.Mashup.Error.Context = User". Error code: 104100.    Investigation:   Reproduction Steps:  Create a Dataflow Gen2 and in the Data destination settings, choose the default Lakehouse destination and save it:  Proceed with the refresh.  The refresh completes successfully without any issues.  Also, if we modify the Data destination to a Lakehouse and select the single schema for all destination tables and save it:  Trigger the refresh again.  The refresh succeeds as expected.  But the issue is when we, update the Data destination to a Lakehouse, but this time map the tables to multiple different schemas instead of a single schema and save it: Initiate the refresh. The refresh fails and throws the below error:  Observed Behavior The failure occurs only when multiple schemas are configured as the destination. The issue is reproducible across refresh attempts. The Dataflow Gen2 UI allows selecting multiple schemas, but the refresh runtime does not handle this configuration correctly. Additional Observation (UI Inconsistency) When “Full hierarchy” is set to True in the Dataflow Gen2 data destination: The runtime effectively expects one schema for all tables. However, the UI still allows users to select different schemas per table. Saving this configuration is allowed, but refresh fails afterward. This strongly suggests a design inconsistency rather than an intentional limitation.   Current Workaround & Impact To work around this issue, we are currently: Creating multiple Dataflow Gen2 instances Each Dataflow writes to the same Lakehouse, but only one schema per Dataflow.   Due to this limitation, the number of Dataflows that need to be created and maintained has increased significantly.   Ask to Product Team If multiple schemas are not supported, the UI should prevent users from configuring them. If the UI allows this configuration (as it does today), Dataflow Gen2 should support writing to multiple schemas within the same Lakehouse without refresh failures. We request the Product team to: Review this behavior as a potential defect or design gap Align the runtime behavior with the UI experience Consider enabling multi‑schema destinations in a single Dataflow Gen2, or clearly blocking it in the UI if unsupported   This enhancement would significantly improve usability, scalability, and customer experience when working with structured Lakehouse environments. ... View more

Hello  ,   I would like to suggest a new workspace item. A simple wiki. Although it could be integrated within a notebook, this could be overwhelming for people who mostly build reports or similar. Another key benefit of a separate wiki item could be the ability to display it on the workspace landing page. This would replace the 'Import... View' option. To me, as a developer, this looks like a space that needed to be filled somehow, a wiki page would make more sense. ... View more

The current card visual forces users to overlap elements or waste copious amounts of time creating custom visuals. The new card feature should give users the ability to create multiple cards in a single container and provide a greater level of customization. ... View more

It would be beneficial to incorporate features from Pivot tables that allow for the expansion and collapse of columns and hierarchical column groups within tabular visuals. This would not only solve the current limitations of matrices but also provide report creators with the flexibility to hide and show rows and columns, saving these settings for future use, thus eliminating the need to scroll through irrelevant data. ... View more

When a scheduled refresh completes with warnings such as "Cannot convert value 'xx' of type Text to type Number", the warning message in refresh history does not include the table name and column name where the issue occurred. Data refresh in Power BI - Power BI | Microsoft Learn To enable all users to easily investigate the root cause of the warning, please include the affected table name and column name in the refresh history warning message. ... View more

When using the Dataflow Query Execution REST API Query Execution - Execute Query - REST API (Dataflow) | Microsoft Learn queries are terminated after ~90 seconds.   This fixed timeout significantly limits real‑world usage. Only very small or simplified queries can be executed, while more complex or parameterized queries (although valid and supported in normal Dataflow refreshes) are cancelled. This limitation makes it difficult to: Build generic or reusable Dataflow solutions Execute dynamic or complex queries via automation Use the API consistently compared to pipelines Suggested improvements: Increase the default timeout Make the timeout configurable   Many users aim to build generic, reusable, and automated Dataflow solutions in Fabric. The current timeout makes this difficult and forces unnecessary workarounds, such as: Over‑splitting queries Avoiding the API altogether Falling back to less flexible execution methods Improving this would unlock significantly more value from the Dataflow Query Execution API. ... View more

Enabling customized calculations at the query level for subtotals and grand totals would offer greater flexibility in reporting and preserve performance. Efficient organization of control settings to modify the style of these totals separately will empower report creators to achieve their desired appearance, while addressing their need for more control and customization in reporting. ... View more

Imagine a world where report creators can automatically apply slicer and filter selections based on specific logic, revolutionizing data analysis and user experience. This innovative approach eliminates any need for complex workarounds, optimizes slicer functionality, and paves the way for more efficient and effective data reporting. ... View more