Enforcing OneLake Security on external semantic model API calls without adding security risks
Problem External applications cannot query Fabric semantic models on a user’s behalf - with OneLake RLS security rules enforced - unless the Fabric API is exposed to any and every client an authorized user might decide to install and try out. Ungoverned API access is a security risk: users might unwittingly funnel data to an unapproved AI service or install a compromised open-source tool that exfiltrates it. Organizations must accept this risk to enforce OneLake security on semantic model calls from external applications. This practical limitation keeps OneLake security from delivering on its “define once, enforce everywhere” promise. Details The “Semantic Model Execute Queries REST API” tenant setting is scoped by identity only. If an application needs to query a semantic model for its users, every user must be granted API access. There is no way to say "you can use the API to get data from Fabric, but only through this application" - users may connect to Fabric using any external system they choose. Every other method of enforcing access restrictions (passing in effectiveUserName or impersonatedUserName in a service principal call) breaks onelake security. Current workarounds and security solutions fail: A service principal with impersonatedUserName does not pass the user’s Entra identity to OneLake. An Entra user as a service account for impersonatedUserName passes the wrong Entra identity to Onelake, and additionally it is an anti-pattern that depends on interactive sign-in which is not suitable for enterprise applications. Some features (Private link, IP allow-lists, Azure API management, conditional access) can be configured to limit access to Fabric, but any setting that sufficiently restricts API access also negatively impacts protal access and/or functionality. For example - email distribution and on-premises data gateways are not compatible with tenant private links, workspace IP allow-lists limited to the external application would block legitimate inter-workspace traffic (if model and lakehouse are in different workspaces), and workspace private links explicitly do not support semantic models in the first place. See forum thread for detailed discussion: Controlled "Semantic Model Execute Queries" REST API Access for Fabric Users | Microsoft Fabric Community Request Provide a supported way for an application to query a semantic model on behalf of a user such that: Authorization to call the API is granted to the application, not to its users. Data access is evaluated as the end user, using their real Entra identity, so OneLake security and SSO Direct Lake apply the same permissions they would in the portal. The user cannot call the API from other clients unless they have been separately granted access. How this is implemented — an OBO flow, a delegated token, a new tenant setting, or something else — is Microsoft’s call. The requirement is that the application is the authorized caller and the user is the effective identity.
Display the Business Names in Power BI report when using ODBC connection to connect to Datasphere.
Currently we are only able to see the technical names displayed in Power BI when the Datasphere report is exposed to Power BI using the ODBC connection. It would be better if we have the option to display the Business Names from Datasphere Graphical views to make sure the renaming on the same can be ignored in Power BI .
Power BI Dynamic Subscription Capacity Consumption and Recipient Processing
Issue: The concern is that the dynamic subscription workload can consume a significant amount of capacity when generating and distributing personalized report outputs. This creates a scalability concern for customers who want to use Dynamic Subscriptions for a larger number of recipients while continuing to run their existing Power BI workloads on the same capacity. How Customer is Expecting: The customer is requesting an enhancement or configuration option that would provide better control over how Dynamic Subscription workloads are processed. In particular, the customer would like the ability to: Process individualized subscription outputs in a sequential or controlled manner, rather than potentially having multiple personalized report-generation operations place significant load on the capacity during the same processing period. Have an option to control or limit subscription processing concurrency, if applicable, to prevent a Dynamic Subscription workload from causing a sudden capacity utilization spike. Reduce the impact of Dynamic Subscriptions on other workloads running on the same Fabric capacity. The customer's primary expectation is that Dynamic Subscriptions should be able to distribute individualized reports to multiple recipients without unexpectedly consuming the majority of the available capacity. If sequential processing is technically feasible, the customer would prefer an option where personalized reports are processed in a controlled sequence or with configurable concurrency so that capacity consumption can be distributed over time instead of potentially creating a large utilization spike. The customer would like to expand the use of Dynamic Subscriptions for additional reports and recipients. However, the observed capacity consumption creates concern regarding the scalability of the feature on their existing capacity. Having configurable processing behavior or improved capacity management for Dynamic Subscriptions would allow customers to adopt this functionality more broadly without significantly affecting other Power BI/Fabric workloads running on the same capacity.
Managing Purview Access in a OneLake Security-Enabled Fabric Environment
As OneLake Security is now enabled by default for supported Lakehouse items, Purview scanning appears to work differently for Lakehouses created before and after this change. We are therefore looking for a centralized solution for managing Purview access across Fabric Lakehouses. Assigning the Contributor role to the Purview Service Principal, as recommended, is unfortunately not an option for us due to our security and governance requirements. We are looking for a solution that follows the principle of least privilege while minimizing operational overhead. Ideally, Purview should be able to access all relevant Lakehouses without requiring manual role assignments for each existing and newly created Lakehouse. Could the Product Group please advise whether a centralized approach is planned, for example: A tenant- or Fabric-level Default Reader, that can be assigned once and automatically applies to all Lakehouses. Automatic inheritance of OneLake Security permissions for new Lakehouses; Or another centrally managed mechanism that avoids per-Lakehouse configuration while maintaining read-only access? Disable OneLake Security for specific Fabric
Org apps - Cannot be arranged in folders and do not stay hidden
Currently, Organizational Apps (Org Apps) are displayed in the standard Apps section of the Get Apps experience, alongside regular workspace apps. For organizations managing large-scale Power BI deployments, this creates navigation and discoverability challenges. **Current Behavior:** Org Apps appear mixed with regular apps in a single list, making it difficult for end-users to distinguish and locate organizational-level content, especially in environments with dozens of apps. **Requested Behavior:** Add the ability to display Organizational Apps in a separate, dedicated section within the Get Apps experience (similar to how Featured and Recommended apps are organized separately). This would: - Improve discoverability for org-level content - Create clear visual separation between user-scoped and organization-scoped apps - Enhance the app navigation experience at scale **Business Impact:** Organizations deploying large numbers of apps (particularly during migrations and multi-tenant rollouts with 100+ apps) would benefit significantly from dedicated Org Apps visibility. This is especially valuable for external-facing platforms serving multiple client organizations, where organizational apps serve as the primary content distribution mechanism. **Suggested Implementation:** Add a new collapsible "Organizational Apps" section in the Get Apps experience that displays all Org Apps separately from regular workspace-published apps. Admins should have the option to control this visibility via tenant or workspace settings. **Workaround:** Currently unavailable.📉 How Would You Investigate a 20% Drop in Revenue?
A data analyst shouldn’t stop at identifying what happened. The real questions are: Where did the decline occur? → Why did it happen? → What caused it? → What should we do next? By analyzing regions, products, customers, time periods, and key business metrics, raw data can reveal the root cause behind the numbers. Good data analysis turns numbers into decisions. 📊 #DataAnalysis #BusinessIntelligence #PowerBI #MicrosoftFabric #DataAnalyticsUnable to access shortcuts using spark
I have created shortcuts between same tenant lakehouses using a service principal through the REST API endpoints. I am not able to query the tables using spark using either relative or full abfss paths. For example using a helper function that defines the workspace, lakehouse and table name. I have confirmed that the code works so it's not my helper function that is the problem. abfss_path = f"abfss://{workspace_id}@onelake.dfs.fabric.microsoft.com/{lakehouse_id}/Tables/{table_name}" df = spark.read.format("delta").load(abfss_path) df_dimlot = load_table("gold", "dimlot") Instead the error that is raised is this bad request 400. Operation failed: "Bad Request", 400, HEAD http://onelake.dfs.fabric.microsoft.com/85dc7dd8-859e-447b-ac58-cf9ceaea8bc9/0765a6d2-0972-4ee7-a7bb-1e17666b566a/Tables/dimlot/_delta_log?upn=false&action=getStatus&timeout=90s rId: 0d717e82-201f-0010-7034-568c00000000 The user i am trying to query using spark is contributor on both the workspace that has the original target data and also the workspace where the shortcut is now created. It has direct contributor access on the lakehouses which are the target and destination lakehouses. Troubleshooting already done Confirmed the consumer DP_Gold lakehouse ID and OneLake path. Confirmed dimlot exists as a managed Delta table/shortcut in the consumer lakehouse. Confirmed the shortcut points to the central Data Platform Gold lakehouse. Compared workspace, direct item, and OneLake role access for my user and the test user. Confirmed the failure occurs in an interactive session and that runtime context identifies me as Kasper Pedersen. I have not changed or recreated the roles as part of this investigation. Help requested Please inspect the request ID and explain why OneLake returns HTTP 400 for this user’s HEAD .../_delta_log request. Please confirm which identity and effective permissions Spark/OneLake use when resolving this cross-workspace shortcut in an interactive notebook. Is trusted-service-user from Spark SQL expected in this scenario? Given the configured Contributor access and target Test role, is any additional permission or identity mapping required at the shortcut source or target? Is reading this shortcut through spark.read.format("delta").load(abfss_path) supported for this configuration, or must it be resolved through the lakehouse catalog?Add Continuous Incremental Synchronization for Fabric ClickHouse Accelerated OneLake Tables
Fabric ClickHouse provides accelerated access to OneLake data for high-performance analytical workloads. For operational analytics and AI applications, a point-in-time accelerated copy can quickly become stale as the underlying OneLake table changes. Please add continuous incremental synchronization for accelerated OneLake tables in Fabric ClickHouse. The synchronization should process new Delta or Iceberg table versions incrementally and apply inserts, updates, and deletes where supported. Users should be able to configure a freshness target such as near real time, every minute, every five minutes, scheduled, or manual. The monitoring experience should show the source table version, last synchronized version, current synchronization lag, rows processed, failures, and checkpoint status. OneLake should remain the governed source of truth while ClickHouse maintains a continuously fresh accelerated representation for interactive analytics, applications, and AI workloads.Add Cross-Engine Effective Access Trace for OneLake Security
OneLake Security is designed to provide centralized security across Fabric experiences and query engines. As more workloads rely on the same security model, administrators need an easy way to understand why a specific user can or cannot access a specific table, row, or column. Please add an Effective Access Trace experience to OneLake Security. An administrator should be able to select a user or service principal, a OneLake object, and an access path, then see the complete security evaluation that produced the final result. The trace should show applicable OneLake roles, inherited permissions, table permissions, row filters, column restrictions, group membership, sensitivity or policy restrictions, and the final Allow or Deny decision. It should also show the effective result across supported access paths such as Spark, SQL analytics endpoint, Direct Lake, OneLake APIs, shortcuts, and authorized external engines. If access differs between engines, Fabric should clearly identify which rule or unsupported security behavior caused the difference. This would make centralized OneLake Security much easier to validate, troubleshoot, and operate in large enterprise environments.
