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.
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-overviewSupport 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.Schedule Data Pipeline to run as a Service Principal
Please make a UI (user interface) option to schedule a Data Pipeline to run in the user context (security context) of a Service Principal instead of my personal user. This should also have the effect that any Notebooks within the Data Pipeline are run in the security context of that Service Principal.Overview of all Item permissions in a Workspace
We need a single page overview where we can see a complete list of which users and security groups have item permissions on any Item in the workspace. Today, we need to click on every single Item to see who has access to that item. We need a complete overview to easily spot if someone has a permission that they should not have.
