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

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

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

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

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

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

Current behavior Today, Microsoft Fabric controls item creation through a single tenant or capacity‑level setting: “Users can create Fabric items.” This setting works on an all‑or‑nothing basis: When enabled, users can create all Fabric item types in a workspace. When disabled, users cannot create any Fabric items. There is currently no supported way to selectively allow or block specific Fabric item types (for example, allowing users to create only reports but not Lakehouses, Warehouses, Pipelines, etc.). Problem / customer impact Many organizations have strong governance and separation‑of‑duties requirements. Common scenarios include: Allowing report developers to create only Power BI reports Allowing data engineers to create data engineering objects only Preventing accidental creation of high‑impact objects (e.g., Warehouses, Lakehouses, Pipelines) Because item creation is all‑or‑nothing, admins are forced to: Over‑restrict users (Viewer role), or Over‑expose capabilities that users should not have This creates friction, governance risk, and additional administrative overhead through workarounds such as multiple workspaces per persona. Requested enhancement Provide granular creation controls that allow admins to: Enable or disable specific Fabric item types per tenant, capacity, or security group Align Fabric permissions more closely with real‑world organizational roles Improve governance without limiting adoption or usability Benefits Stronger security and governance Better role separation without workspace sprawl Reduced risk of unintentional resource creation Improved admin and customer experience ... 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

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

Today, Workspace Monitoring is configured separately per workspace, which introduces maintenance overhead and likely also a repeated baseline CU cost for each workspace.   Please make it possible to create Workspace Monitoring instances that cover multiple workspaces.   Users should be able to decide how many monitoring instances to configure and which workspaces each instance covers.   This would allow the baseline monitoring cost to be shared rather than incurred separately per workspace, reducing overall cost while also simplifying configuration and ongoing maintenance. In addition, it would enable a more centralized and flexible monitoring setup across workspaces. ... 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

We have been observing that Power BI semantic models are automatically triggering a refresh immediately after being republished to the Power BI Service. In the refresh history, this is tagged as "On-demand", even though no manual action was performed. Upon reaching out to Microsoft, we received the following confirmation: “This is the expected behavior from the Power BI Service once a semantic model is republished. The behavior is by design and applies to all semantic models in Import mode (or those using auto-aggregations). This behavior has been consistent for several years, and there are currently no plans to change it in the product roadmap.”   While this behavior can be beneficial in certain scenarios—particularly for smaller models that complete refreshes within seconds—it introduces challenges in the following cases: Incremental Refresh Models:  In some situations, the refresh may process more data than expected, leading to longer execution times. Large or Complex Models: Models with sizes exceeding 5–10 GB or with high complexity may require several minutes to refresh, increasing resource consumption.   This behavior can significantly impact capacity resources, especially in Fabric capacity-enabled workspaces, where such unintended refresh activity may lead to unnecessary resource utilization and potential performance issues.   It would be highly beneficial if this behavior could be controlled at the user level or at least at the tenant level, allowing organizations to prevent unintended refreshes and better manage capacity consumption. ... View more

  Description / Problem Our organization has fully enforced phishing‑resistant authentication methods for all employees and administrative accounts, in line with Microsoft security best practices. These include passkeys and FIDO2 hardware security keys (for example, YubiKey). However, we currently need to maintain Power BI on‑premises data gateway (February 2026 version) as an exception to these policies. The reason is that the embedded web authentication engine used by the gateway does not support FIDO2 authentication. Because of this limitation, we are unable to enforce phishing‑resistant authentication methods for gateway sign‑in and administration. Current Behavior The Power BI on‑premises data gateway currently supports: Password‑based authentication, or Passwordless authentication using number matching While number matching improves security, it does not meet the definition of phishing‑resistant authentication required by many enterprise security and compliance standards. Impact Forces organizations to maintain authentication exceptions Creates a security gap in otherwise fully phishing‑resistant environments Prevents full alignment with Zero Trust and passwordless‑first strategies Affects enterprises with strict regulatory, compliance, or security mandates Requested Enhancement Please add FIDO2 authentication support (passkeys and hardware security keys) to the Power BI on‑premises data gateway in a future update. This would allow organizations to: Fully enforce phishing‑resistant authentication across all Fabric and Power BI components Eliminate password‑based authentication for gateway administration Align the gateway with Microsoft’s broader identity and security roadmap ... View more

Interpreting visuals without a clear legend to indicate logic behind specific styles can lead to confusion and decision-making errors. An idea to enhance clarity and transparency by ensuring legends and tooltips accurately display colors, patterns, and other visual components influenced by logics, would enable report consumers to easily understand the applied logic and make more effective decisions. ... View more

Power BI and Microsoft Fabric currently do not offer a tenant‑level or portal‑wide banner capability that allows administrators to proactively notify all users when data is stale, delayed, or impacted by upstream system failures. In real‑world enterprise environments, pipelines, dataflows, and semantic models frequently depend on external source systems. When these sources are unavailable or delayed, reports may continue to load successfully but display outdated data, creating a silent failure scenario. Users have no visible indication that the information they are viewing may not be reliable. Today, administrators lack a centralized, in‑product mechanism to communicate these conditions to all users at the moment they access Power BI / Fabric. ... View more