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.
Parameterize Dataflow Gen2 data source connection
Allow the Dataflow Gen2 data source connection GUID to be parameterized and stored in a Variable Library. This would allow the same Dataflow to use different connections depending on the workspace/environment, without modifying the Dataflow itself. Hypothetical example: Variable Library: SourceConnectionGuid = 01234567-89ab-cdef-0123-456789abcdef The Dataflow references this variable for its data source connection. In another workspace, the same Dataflow could use: Variable Library: SourceConnectionGuid = fedcba98-7654-3210-fedc-ba9876543210 This would make it much easier to use the same Dataflow across personal feature workspaces, test, and production while keeping the appropriate connection for each environment.Support OneLake Security-Enforced Data Sources in Fabric IQ Ontology
Fabric IQ Ontology is designed to provide governed business context across enterprise data, while OneLake Security is becoming the central fine-grained security model for Fabric. These capabilities should work together directly. I would like Ontology data bindings to fully support Lakehouses that use OneLake Security, including table/folder permissions, row-level security and column-level security. Ontology queries, Graph exploration, Data Agents and other consumers should respect the effective OneLake permissions of the requesting identity. Administrators should not have to choose between securing a Lakehouse with OneLake Security and using that data as part of a Fabric IQ ontology. Integrating the two would provide a consistent security boundary from OneLake data through business concepts, relationships and AI experiences.Allow External OneLake Data Shares to Be Accepted into Multiple Fabric Item Types
Fabric External Data Sharing provides an excellent zero-copy mechanism for sharing OneLake data across tenants. However, the receiving tenant currently has to accept the share into a Lakehouse. I would like the consumer to be able to choose the Fabric item that best matches the consuming workload, including Lakehouse, Warehouse, Eventhouse/KQL Database and SQL Database where technically applicable. For example, a team whose primary consumption environment is Fabric Warehouse should not need to create and operate an additional Lakehouse simply to receive an external share. The external share should remain governed and read-only while appearing natively in the selected Fabric workload. This would make cross-tenant OneLake sharing more consistent with Fabric's multi-workload architecture and reduce unnecessary intermediate items.Allow OneLake Shortcut Authentication Mode to Be Changed In Place
OneLake shortcuts support passthrough and delegated authentication, but changing the authentication model currently requires deleting and recreating the shortcut. I would like shortcut authentication and connection settings to be editable in place. Administrators should be able to change a shortcut from passthrough to delegated authentication, replace the delegated connection identity, or move back to passthrough without deleting the shortcut. Fabric should validate the new identity and permissions before applying the change and preserve the shortcut object, downstream references, lineage and dependent workloads. For enterprise environments, security models and service identities evolve over time. Recreating shortcuts increases operational risk and makes automation more difficult. Making authentication a manageable property of the shortcut would improve lifecycle management, security operations and CI/CD.Add an "Explain Effective Access" Experience for OneLake Security
As OneLake Security expands across tables, folders, rows, columns and shortcuts, determining why a specific user can or cannot access data can become difficult. I would like Microsoft Fabric to provide an "Explain Effective Access" experience for OneLake. An administrator should be able to select a user, service principal or group and a OneLake path and see: - workspace and item permissions - applicable OneLake security roles - RLS and CLS policies - shortcut-path permissions - target-path permissions - whether passthrough or delegated authentication is being used - which identity each query engine uses - the resulting effective access - the specific rule responsible for allowing or blocking access The same information should be available through an API for security automation and audit tooling. This would significantly simplify troubleshooting, security reviews and least-privilege validation in enterprise Fabric environments.
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 ownerEnable 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.
Power BI REST + PowerShell parity without Tenant Admin
Summary Item‑level APIs/cmdlets so engineers can automate what the UI can do without requiring Tenant Admin scopes. Problem Key actions (e.g., sensitivity labels) are admin‑only via REST; others lack item‑level endpoints. Ownership/permissions and structured deployment need elevated roles or manual UI. This blocks least‑privilege automation. Proposed solution - Item‑scoped endpoints/cmdlets to: - **Set/Get item permissions** on paginated reports. - **Set/Get sensitivity labels** at item scope (honor label policy) without admin. - **Create/list/move to folders** and deploy RDLs to them (see Folders idea). Acceptance criteria - A Service Principal with workspace **Contributor** can set a paginated report’s permissions and sensitivity label via API (no Tenant.ReadWrite.All), and move/deploy it into a folder path. Impact Enables proper DevOps with least privilege; removes brittle manual steps.
Enhance Power BI/Fabric Audit Logs with Detailed Action Tracking and Change History
Power BI and Microsoft Fabric audit logs are essential for governance, compliance, security monitoring, and operational auditing. However, several important activities are currently logged with very limited detail, making it difficult to accurately assess user actions and configuration changes. 1. Copilot Audit Logs Today, interactions with Power BI Copilot are typically recorded under the generic RequestCopilot event. As a result, administrators cannot distinguish users who simply submitted prompts from those who performed actions on the generated results. For example, it is currently not possible to identify: Users who only viewed Copilot responses. Users who executed Copy Table. Users who copied generated content. Users who exported or downloaded results generated by Copilot. From a governance, compliance, and data protection perspective, these actions have very different risk profiles and should be tracked separately. Requested enhancement: Introduce dedicated audit events and/or action details for activities such as: CopyTable CopyResponse ExportResults DownloadGeneratedContent Other user actions performed against Copilot-generated outputs 2. Update App Audit Logs The current UpdateApp audit event also lacks sufficient detail for auditing purposes. When an app is updated, administrators cannot easily determine: Which reports were added or removed. Which audiences were modified. Which users or groups were impacted. Which permissions changed. What specific configuration changes were applied. This makes troubleshooting, change management, audit investigations, and compliance reviews significantly more difficult. Requested enhancement: Provide a detailed change log (delta) within the UpdateApp event, including: Added content Removed content Audience changes Permission changes User/group assignments added or removed Before/after configuration details Business Value More detailed audit logs would significantly improve: Security monitoring Data governance Regulatory compliance Internal and external audits Incident investigations Change management Risk management As organizations continue adopting Copilot and Fabric at enterprise scale, audit logs must evolve from activity indicators into true operational and security records that provide full traceability of user actions and configuration changes.
