Fabric Gateway Connection Lineage View.
Fabric Gateway Connection Lineage View. The Lineage view would provide administrators with visibility to all dependencies on a connection. Identifying all impacted resources in order to consolidate connection sprawl and apply governance standards would be extremely helpful. The Lineage output should be able to be exported to csv.Workspace-Level Control for Export to Excel in Power BI/Fabric
Scenario In enterprise environments, organizations often require: Workspace-level governance for data export. Security group-based control for export permissions. Different export policies depending on workspace, data classification, or business domain. Approval from security teams based on the sensitivity of the data in each workspace. For example, a user may be allowed to export data from Workspace A, but should not be allowed to export data from Workspace B, even if they are the same user and both workspaces exist in the same tenant. Current Behavior Currently, Export to Excel can be controlled through the tenant setting and scoped to specific security groups. However, this control is not available at the workspace level. This effectively means: Export permissions are controlled broadly at the tenant/security group level. The same user or group cannot have different Export to Excel permissions per workspace. Workspace-specific export governance is not natively supported. Organizations must rely on workarounds such as content separation, access restructuring, or report-level export settings where applicable. Expected Behavior From an enterprise governance perspective, we would expect: Ability to control Export to Excel at the workspace level. Support for combining workspace scope + security group scope. Ability to allow a user/group to export from one workspace but block export from another. Alignment with data classification and security approval processes per workspace. Why this matters Export to Excel can expose sensitive or regulated data outside Power BI/Fabric. Many organizations classify data at the workspace or domain level, so export permissions need to follow that same governance model. Tenant-wide or security-group-only control does not provide enough granularity for enterprise security requirements. Feature Request We would like to request support for: Workspace-level Export to Excel control. Security group-based export permissions per workspace. Ability to define different export policies for different workspaces. Improved governance alignment with data classification and security review processes.
Let Workspace Admins manage Fabric Policies
For example, allow a Workspace Admin to grant other identities the Contributor role, while also granting them higher privileges in certain areas, e.g. List Workspace role permissions (without reshare ability) List Workspace settings (without modify ability) Modify certain workspace settings (e.g. Spark compute settings) Basically, give Workspace Admins the option to apply more granular workspace permissions to other users/identities. An example use case: Let an SPN, or Workspace Identity, act as a read-only Admin, allowing the SPN to regularly (on a schedule) audit workspace settings - using a notebook that does API calls to list actual workspace settings and assert them against a hard coded expected workspace settings. This would be a great way to audit our Fabric workspace settings, workspace roles and OneLake permissions, being a team who are not tenant admins ourselves, we would like to use an SPN or WI that we grant read-only Workspace Admin permissions to automate workspace auditing. https://learn.microsoft.com/en-us/fabric/governance/fabric-policies-overview
Allow Org App Publishing Without Write Permission on Underlying Semantic Models
Allow users to create, curate, and distribute Org Apps without requiring Write permission on the underlying semantic models. Org App distribution should support separation of duties between semantic model owners and app publishers. A user responsible for packaging and distributing approved reports should not need permission to modify the production models those reports depend on. Our semantic models go through formal CI/CD and version control. Providing write to downstream users violates our strong governance and is preventing adoption of Org apps.Support Fabric SQL Database with workspace-level inbound Private Link
Fabric SQL Database supports tenant-level Private Link but not workspace-level Private Link. Securing a small number of databases therefore requires enabling Private Link across the entire tenant, introducing unnecessary operational constraints for unrelated workspaces, Power BI workloads and on-premises data gateways.
Get Secret from Azure Key Vault using Fabric Workspace Identity
Users can access key vault secrets using notebookutils.credentials.getSecret. This is based purely on the user's access (or object owner's access, if the notebook is being run in a pipeline). In larger organizations, managing access at the individual level is not scalable. It would be preferable to associate key vault privileges with a service principal so that connections keep running if a particular user leaves the business. The workspace identity is an obvious candidate to be given key vault permissions. While this is technically possible - we can add key vault privileges to a workspace identity's associated entra ID app service principal - the service principal's credentials are not used by the notebookutils.credentials.getSecret method. (At least based on my current understanding - this seems to be a known limitation if you read related posts in the Fabric user forums as of August 2025). Please make it possible to access key vault secrets using workspace identities.Enable Ownership Change / Take‑Over for Mirrored Database Items in Fabric
Mirrored DBs do not support ownership transfer today. This becomes an issue when someone leaves the company. And the user tied to the ownership is beeing disabled. That means you need to recreate the whole mirroring database and recreate all shortcuts, jobs pipelines etc etc.. Alot of work. The Take‑Over functionality exists for other Fabric items but excludes mirrored DBs. This is a critical operational need for enterprise workloads. Please consider developing this functionality.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.More Granular Workspace Permissions (RBAC)
Allow Workspace Admins to assign more granular permissions and create custom roles based on atomic permissions, following the principle of least privilege. Examples of possible atomic permissions: Read workspace settings Manage workspace settings Read workspace role assignments Manage workspace role assignments Read OneLake security access role assignments Read workspace activity logs Read data Write data Share read data permissions Share write data permissions Create and edit workspace items Delete workspace items Share create and edit workspace items Share delete workspace items etc. This would enable Workspace Admins to automate auditing and governance, delegate specific responsibilities, and follow least-privilege principles without granting unnecessarily broad workspace roles.
