Power BI Dashboard Subscription Issues - Requested Improvements and Potential Solutions
Hello Power BI Support Team, We have encountered two issues with the updated Power BI dashboard subscription and email delivery functionality. Please investigate these issues and advise on possible solutions. Automatically sent dashboard emails are saved in the Sent Items folder All automatically distributed dashboards appear in my Sent Items folder, resulting in a significant accumulation of unnecessary messages. At least two dashboards are sent daily to approximately 60 users, generating more than 120 sent messages per day. Suggested solution: Please provide an option to prevent automatically generated subscription emails from being saved in the sender's Sent Items folder. Alternatively, please clarify whether this behavior can be controlled through Power BI, Outlook, or Exchange settings. Using a dedicated service mailbox could also be considered, provided it effectively addresses the issue. Expected outcome: Reduce unnecessary email accumulation while maintaining the current automated distribution process. Poor dashboard image quality on mobile devices Dashboards are distributed via email and opened on mobile phones. However, the content appears blurry and difficult to read, preventing users from properly interpreting the data. Suggested solutions: Please investigate whether the issue is caused by image resolution, rendering, or scaling during email delivery. We suggest replacing static dashboard images with links to interactive Power BI reports optimized for mobile viewing. Where applicable, a dedicated mobile layout should be configured for these reports. If static images must remain part of the email subscription, please advise whether their resolution and rendering quality can be improved. Expected outcome: Ensure that dashboard data remains clear, readable, and accessible on mobile devices. Request Please investigate both issues and recommend the most effective technical solutions. Please also clarify which improvements can be implemented through existing configuration settings and which would require product enhancements. Thank you for your support.
Power BI Report Subscription - Restore Line Break Formatting
After the recent update, report subscription content is being generated as a single paragraph with all information combined into one block of text. This makes the output difficult to read. Please restore the previous formatting so that content is generated in distinct sections with appropriate line breaks and spacing.
New tab should not retain opened Workspaces and artifacts
Since the recent UI changes, Microsoft Fabric keeps opening workspaces/items in additional tabs and retains many workspace tabs simultaneously. This makes navigation difficult and increases browser clutter when working across multiple Fabric workspaces throughout the day. Please provide an option to revert to the previous behavior or allow users to configure whether workspaces/items open in the current tab versus a new tab. A user-configurable setting would improve productivity and reduce tab management overhead. I use a Fabric daily,working with Lakehouses, Warehouses, Pipelines, and Notebooks, in multiple workspaces for all the ENVs (Dev/Test/PROD). I want to see artifacts related to one ENV in one tab which was there before and not now. which is making it harder to track active work and slowing navigation.
Add Comparison Semantics Options to the Power BI Filter Pane
Add Comparison Semantics Options to the Power BI Filter Pane Description I would like to request an enhancement to Power BI that allows report developers to select the comparison semantics used when filtering a field in the Filter pane. Currently, Power BI applies predefined comparison behavior that developers cannot explicitly control through the Filter pane. This can lead to unexpected results, particularly when comparing blank values with default values or when comparing values across different data types. I propose adding a Comparison Behavior option to the Filter pane whenever a field is added as a filter. The developer could choose from three comparison semantics: Strict identity — Values must match exactly, including their data types. Blank values remain distinct from default values. Identity — Values can match across data types when their values are equivalent, but blank values remain distinct from actual values. Equality — Values can match across data types, and blank values may match the default value of their data type. Example Use Case Consider a Boolean field named Is Deleted containing True, False, and blank values. When a developer selects False in the Filter pane using equality semantics, Power BI may also include blank records because blanks can be treated as the default Boolean value, False. With strict identity semantics, selecting False would return only records explicitly marked False, excluding both True and blank values. The same flexibility could benefit numeric, text, and other supported data types where the distinction between a blank and a default value matters. Expected Behavior When a developer adds a field to the Filter pane, provide an optional setting to select the comparison behavior: Strict identity Identity Equality The selected behavior should determine how the filter evaluates values, including blanks and comparisons across data types, wherever applicable. Ideally, this setting would be available at the individual filter level, allowing different fields in the same report to use different comparison semantics. Backward Compatibility The existing default behavior should remain unchanged unless a developer explicitly selects a different comparison option. This would allow existing reports to continue working as expected while giving developers greater control over filtering behavior in new or updated reports. Business Value This enhancement would make filtering more predictable, transparent, and flexible. It would reduce the need for workarounds such as changing column data types, adding DAX measures solely to enforce filtering rules, or modifying upstream data to compensate for filter behavior. Most importantly, it would allow report developers to define filtering behavior according to the business requirements of their reports rather than being limited to a single predefined comparison model.
Support API-Based / Non-Interactive Authentication for Salesforce Connectors in Power BI & Fabric
Salesforce supports API-based access through Connected Apps and API-enabled accounts, allowing integrations to authenticate without user interaction. However, the Power BI/Fabric Salesforce connector currently requires interactive UI-based sign-in and MFA tied to an individual user. This creates challenges for enterprise support and deployment processes: Global support teams cannot manage Salesforce-connected reports if authentication is tied to one person's MFA. Report and semantic model promotion between environments can require re-authentication by a specific user. Support and operational processes become dependent on individual employees rather than managed service identities. User absence, role changes, or employee departures can disrupt support activities. Please add support for API-based, non-interactive authentication methods such as Salesforce Connected Apps, OAuth JWT Bearer Flow, Client Credentials Flow, or service principal-style authentication. This would allow organizations to use Salesforce API authentication instead of UI-based authentication and remove the dependency on an individual's MFA credentials.
Paginated Reports with PowerQuery - Cloud connections for Snowflake connector
Current situation: Power BI report builder used to build a report using Power Query dataset. Report builder picked the right cloud snowflake DB connection (created in Power BI service portal - app.powerbi.com) However, once we deployed / published the report into power bi service portal (workspace), we are not able to see the connection it uses in the background. We only see the disabled connection settings. Refer the screenshot. It would be great if we display the cloud connection information just like how we display for semantic models. Otherwise, we have to download the rdl file from the portal and check the connection ID from the report file and fetch the connection detail from the "Manage Connections and Gateways" page from the portal settings.
Allow multi-column conditions /output in Power BI Activator rules (Power BI visual-based alerts)
Description: When I create an Activator alert from a Power BI report visual, the rule can only evaluate the single column or measure it was created from, and the alert can only reference that same value. This blocks common governance and monitoring scenarios. Example scenario: I wanted an alert for Dev workspaces that sit on a billable (Premium/Fabric) capacity. That needs a condition on both Workspace Name (contains “Dev”) and Capacity/Billing type (not blank). Activator can’t combine the two in one rule, so I had to build the alert in Power Automate with a DAX query instead. Limitations: A condition can use only one column or measure, with no AND/OR across several attributes. The alert message or action can include only that same column. I can’t add related details like workspace name, dataset link, or owner. There’s no way to run a DAX query as the rule logic. Requested improvements: Conditions across multiple columns/measures (AND/OR). Selectable output fields, so the Teams or email action can include several columns, and dynamic links. Optionally, the ability to define the trigger with a DAX query, as the Power Automate “Run a query against a dataset” action does. Impact: Without this, governance and monitoring alerts need a separate Power Automate flow, which is harder to build and maintain than a native Activator rule.Fabric Workspace Operator Role for Pipeline Monitoring and Rerun Operations
Many organizations have dedicated production support and operations teams responsible for monitoring Microsoft Fabric pipelines and responding to failures. Currently, the available workspace roles are Admin, Member, Contributor, and Viewer. While Viewers can monitor content, they cannot rerun failed pipelines. Contributors can rerun pipelines, but they also have permissions to modify pipeline definitions and other workspace artifacts. This creates a governance gap for enterprises that require segregation of duties between development and operations teams. Proposed Solution Introduce a new built-in Operator workspace role with permissions such as: Allowed View pipeline definitions Monitor pipeline runs and run history View execution logs and error details Manually trigger pipeline execution Rerun failed pipeline runs Cancel running pipeline executions Access workspace monitoring capabilities Not Allowed Create, edit, or delete pipelines Create, edit, or delete Fabric artifacts Modify notebooks, lakehouses, warehouses, or dataflows Manage workspace access or permissions Change workspace settings Connect/disconnect Git repositories Business Value This role would: Support enterprise segregation of duties requirements. Enable production support teams to resolve operational issues without granting development permissions. Reduce the risk of accidental changes in production workspaces. Improve governance and compliance. Align Microsoft Fabric with operational models commonly used in enterprise data platforms. Many organizations need a role that sits between Viewer and Contributor, providing operational control without development privileges. An Operator role would significantly improve security, governance, and supportability for Fabric Data Factory workloads. Use Case: Production support team monitors Fabric pipelines, investigates failures, and reruns failed executions, but should not be able to modify pipeline definitions or other workspace assets.Enable Direct Addition of Fabric Data Agents to Microsoft 365 Copilot
Please enable users to add and invoke a Fabric Data Agent directly as a specialized agent in a Microsoft 365 Copilot multi-agent solution. In our current setup, we can’t add a Fabric Data Agent directly to M365 Copilot, so we connect to it through Fabric IQ Data MCP. This approach raises a concern that we need to separately verify whether requests are routed to and handled by the intended Fabric Data Agent. That additional validation makes configuring and testing the multi-agent solution more complex. We request the ability to select and add a Fabric Data Agent directly as a subagent in the M365 Copilot multi-agent configuration, allowing the parent agent to delegate tasks to it directly. This would reduce the additional validation required for the intermediate MCP connection and make the multi-agent setup simpler and more transparent. This request is not a report of a defect in Fabric IQ Data MCP; it is a request for direct Fabric Data Agent integration in M365 Copilot. We also request that the Fabric Data Agent’s existing authentication, data-access permissions, and security policies continue to be enforced when using this direct integration. References: Consume a data agent in Microsoft Copilot Studio (preview) Consume a Fabric data agent as a tool in Microsoft Copilot Studio
