Community AdminThanks for sharing this idea and for explaining the scenario. I can definitely understand why having access to the current user could feel useful, especially for scenarios where you want the experience or data to vary by user.
From a technical standpoint, though, Power Query M operates primarily in the context of data connections and refresh. In M, the concept of a “user” is generally tied to the credentials configured for a specific data source, rather than the person currently viewing or consuming a report.
If Power Query had a function that returned the user authoring a query in the Power Query editor, that value might only be meaningful during the authoring session. Once the semantic model is published, refresh happens in the service, outside of that authoring context. At that point, the value could reflect the identity or environment used for refresh rather than the report viewer. Also, because Power Query results are materialized during refresh, the value would become fixed until the next refresh, meaning all report consumers would see the same value rather than their own username.
For scenarios where data should vary by user, the recommended approach is usually to use supported single sign-on capabilities with the data source, or to implement a role-based design in the semantic model, such as row-level security.
If the goal is to explore a more built-in capability for user-aware behavior, it may be worth creating a separate idea focused specifically on supporting that at the semantic model layer, rather than through Power Query or a new M function. That would help frame the request around the part of the platform that is better positioned to evaluate the current report consumer and apply user-specific behavior.
We appreciate the feedback, though. It’s helpful to understand the kinds of personalization and security scenarios customers are trying to support, and we’ll continue to take that input into account as we evaluate future improvements.
