Make workspace and item session persistence optional
Description The new persistent session behavior in Microsoft Fabric should be optional rather than forced. Currently, Fabric remembers the workspaces and items that were open in my previous session. When I close the browser and later return to Fabric, those items are restored automatically. I would like an option to completely disable this behavior. When I close my browser, I consider that session finished. The next time I open Fabric, I want to start with a clean session with no previously opened workspaces or items restored. This would also make it easier to use separate browser tabs or windows for different tasks. For example one tab for notebooks, pipelines, and lakehouses related to specific data source and another tab for resources related to another source. Persisting and restoring the previous Fabric session makes it harder to compartmentalize work this way. I understand that session persistence can be useful for users who want to continue exactly where they left off, so I am not suggesting that the functionality should be removed. Instead, please provide a user preference such as: Restore previous Fabric session On – Restore previously open workspaces and items Off – Start with a clean Fabric session When this setting is disabled, closing the browser should effectively end the Fabric UI session. Opening Fabric again should start fresh without restoring previously opened workspaces, items, or tabs. Why this matters The current behavior can make Fabric slower and more cumbersome for users who frequently multitask across workspaces and different Fabric experiences. A persistent session is useful when you intentionally want to continue working later. For users who prefer a clean workspace after closing the browser, however, it should be opt-in rather than mandatory.
Allow report creators to download their Own PBIX even when Downloads are restricted at tenant level.
In the current Power BI permission model, PBIX downloads are controlled exclusively through tenant‑level export settings and workspace roles. This creates a significant limitation for multi‑agency or large enterprise environments: enabling PBIX downloads grants broad download access to any user with Contributor permissions in any workspace, regardless of whether that user originally authored the report. What’s missing: Power BI has no concept of “author-level” permissions for published reports. Although the service identifies report contacts and retains semantic model owners for refresh purposes, these fields are not tied to download rights. As a result, report creators cannot download their own PBIX files unless they are manually added to security groups or privileged roles — even when they are the sole developer and publisher of that content. Why this matters: Organizations with strict governance requirements need a middle-ground option that allows report creators to retrieve their own work without exposing underlying datasets broadly across their tenant. Today, the only choices are: Turn PBIX downloading off entirely, or Turn it on for specific security groups (which often include far more users than just the report authors). This limits flexibility, complicates content lifecycle management, and increases administrative overhead. Requested enhancement: Introduce an “owner-only PBIX download” permission that allows the original report creator (or designated report contact/semantic model owner) to download the PBIX file even when global download settings remain restricted. This would enable organizations to give creators access to their own work without expanding download rights for all Contributors. Benefits: Restores creator-level autonomy without compromising data security Reduces administrative overhead for tenants with many workspaces or agencies Provides the exact middle-ground scenario many customers need Aligns Power BI’s ownership model with user expectations in other Microsoft tools Optional implementation ideas: A per‑report toggle: “Allow report creator to download PBIX” A workspace setting: “Creators may download PBIX regardless of tenant-level restrictions” Linking download rights to the report contact field or semantic model owner
Sub Sections In Power Apps
It would be great if you could create sub sections in Power BI Apps. Currently our sections in the power BI App are split out by each business area. It would be great then if you could create sub sections in within the existing section so we could group reports together. For example we currently have a Finance section. It would be great if we could create another sub section in the finance section to group all our ECL reports into a sub section and then all our EIR reports into another section to make the App more uniform and clean. Currently you can only have a main section and no sub sections
Option to disable or bulk-clear Multitasking session tabs in the Left Navigation Pane
Currently, when working in the Fabric/Power BI Service, opening reports, dataflows, lakehouses, or semantic models automatically stacks them as active session tabs directly under the active workspace in the left navigation pane. For developers like me working in tons of reports, this forces my to manually close all reports I worked in one by one when I hit the limit. Requested Solution: Add a 'Close All Tabs' button: Allow users to clear all accumulated open session items in the left pane with a single click. OR Toggle to Disable Multitasking Tab Stacking: Provide a preference in Settings to prevent opened items from auto-stacking in the left navigation bar altogether.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.Microsoft fabric CI/CD deployment using Azure DevOps
Scenario: We are planning to migrate Microsoft Fabric artifacts across tenants using Azure DevOps. I would like to understand the feasibility of this approach and identify which Microsoft Fabric artifacts can be migrated using an Azure DevOps pipeline. Migration Approach: We have two Azure tenants: Tenant 1 and Tenant 2. Tenant 2 has its own Azure DevOps Services environment. The requirement is to migrate Microsoft Fabric items from a workspace in Tenant 1 to a Microsoft Fabric workspace in Tenant 2. To achieve this, I am planning to: Configure Git Integration for the Fabric workspace in Tenant 1 using a Service Principal. Commit the Fabric artifacts to an Azure DevOps repository in a dedicated folder (for example, Fabric Artifacts) within a repository branch. Create an Azure DevOps YAML pipeline along with a Python script that dynamically deploys the artifacts from the repository into the target Fabric workspace in Tenant 2. Use the attached Python script to automate the deployment process. We currently have the following artifact types in the source Microsoft Fabric workspace. I would like to understand whether there are any limitations with this approach and if all of these artifacts can be migrated successfully using an Azure DevOps pipeline. Artifact Types Activator CopyJob DataflowFabric Environment EventStream GraphQL KustoDatabase KustoEventHouse Lakehouse MLExperiment MountedRelationalDatabase Pipeline SQLDbNative SynapseNotebook User Data Functions Variables Warehouse Dataset OrgApp PaginatedReport Report
Support Azure Service Bus namespaces as Managed Private Endpoint targets
Allow Fabric workspaces to create Managed Private Endpoints to Azure Service Bus namespaces so notebooks, Python runtimes, and Spark job definitions can use the Azure Service Bus SDK when public network access is disabled. Support queues and topic subscriptions over AMQP and AMQP-over-WebSockets, with Microsoft Entra ID and workspace identity authentication. This request is for notebook and Spark network connectivity, not Eventstream ingestion.
Allow reports to exist in multiple workspaces with unified refresh
The problem: When reports are copied across workspaces for different departments to access, each copy maintains its own refresh schedule, leading to data inconsistency and multiple sources of truth. The ask: Allow a report to be registered/linked in multiple workspaces while maintaining a single refresh source and unified refresh timestamp. The benefit: Reduced maintenance burden, guaranteed data consistency, simpler governance, and clearer audit trails across departments.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 ?
