Forum Discussion
Issue with Accessing Power BI Admin APIs Using Service Principal (401 Error tryout mode)
- 1 month ago
Hi Venkatesh_ ,
This behaviour is actually expected in App Owns Data scenario. In this model, Power BI only sees the application or service principal, not your actual end users. Because of that, in Activity Logs you will see GUIDs instead of user email IDs, and there is no setting in Power BI to change this.To track real user activity, you need to handle it from your application side. Since your app already knows which user is logged in, you can use that information while generating the embed token. For example, when your backend calls the Generate Embed Token API, you can store details like user email, report ID, workspace ID, and timestamp in your database.
After that, on the frontend, you can use Power BI JavaScript SDK events (like report loaded, page changed, etc.) to capture how the user is using the report. These events can be sent back to your backend and stored along with the same user details. This way you can build your own complete usage tracking and audit report.
Also, even if you are using Effective Identity for RLS, that information is used only internally by Power BI for data filtering and will not come in Activity Logs as user email.
So overall, Activity Log is mainly for service-level auditing, not for detailed end-user tracking in embedded scenarios. For your requirement, maintaining logs in your application is the recommended approach.
Docs Reference
You can refer to below official Microsoft documentation:
Embed content in your Power BI embedded analytics application - Power BI | Microsoft Learn
Audit and usage admin settings - Microsoft Fabric | Microsoft Learn
Power BI embedded analytics Client APIs | Microsoft Learn
Thank you.
Thanks for your response. I was able to resolve the previous issue by assigning my application the Fabric Administrator role in Azure, which allowed me to successfully query the admin endpoints.
However, I’m now facing a different challenge. We use Power BI Embedded within our web application, but I can only see activity logs from the Power BI Service—not from the embedded usage.
Since our clients interact exclusively through the embedded reports (and not directly via the Power BI Service), the current activity logs are not useful for tracking actual end-user behavior. My main requirement is to capture and analyze embedded activity—specifically, client-level usage and interactions.
Do you have any insights on why embedded activity is not appearing in the logs, or how we can capture detailed usage for embedded scenarios?
Hi Venkatesh_ ,
Thank you for the update. What you are seeing is generally expected in Power BI Embedded scenarios. The Activity Log is primarily intended for auditing activities within the Power BI service and does not provide detailed tracking of end user interactions that occur inside embedded reports. If you are using an App Owns Data model, many actions are performed through the application identity, so embedded user activity is not surfaced as individual user events in the audit logs.
For detailed client level usage analysis, such as report views, page navigation, filter changes, or visual interactions, the recommended approach is to capture telemetry within your application using the Power BI Embedded APIs and store those events in your own monitoring or analytics solution. This provides much more granular insight into how your clients are interacting with embedded content than the Activity Log can offer.
Could you confirm whether you are using an App Owns Data or User Owns Data embedding model and which specific user activities you are looking to track?
That will help determine the most appropriate solution for your scenario.
Thank you.
- Venkatesh_2 months agoHelper I
We are using the App Owns Data approach for Power BI Embedded. I noticed that in the activity logs, the UserId column shows GUIDs instead of actual user emails. These GUIDs appear in events like GenerateToken and ViewReport.
I’m assuming these might be related to embedded activity, but I’m not entirely sure.
Could you help clarify:Why are we seeing GUIDs instead of user email IDs?
Is this expected behavior for App Owns Data scenarios?
Is there any way to map these IDs back to the actual end users (e.g., via token generation or custom logging)?
Or are we missing some configuration that would allow capturing user identity in the logs?At the moment, it’s difficult to track real client usage since we cannot associate activity with actual users
- v-tejrama2 months agoCommunity Support
Hi Venkatesh_ ,
Yep, this is expected behavior in an App Owns Data scenario. Since the app or service principal is the identity talking to Power BI, the audit and activity logs usually show object IDs or GUID-based identifiers instead of the actual email addresses of the end users viewing the embedded reports.
There isn’t a setting that will automatically replace those GUIDs with your application users in the Power BI Activity Log. Even when end users are authenticated through your app, Power BI audit logs aren’t meant to give full end-user attribution for embedded usage. So the GUIDs you see in events like GenerateToken and ViewReport usually can’t be used on their own to identify the actual client who viewed the report.
If you need client-level usage tracking, the usual approach is to keep that correlation in the application layer. Since your app knows which user is authenticated when an embed token is generated, you can log that user information alongside report access events and use it to build a complete audit trail of report consumption.
If you’re using effective identities for row level security, those identities help determine what data a user can access, but they aren’t automatically surfaced as user email addresses in the Power BI Activity Log. Based on your description, this seems like expected platform behavior rather than a missing setting or configuration issue.
Thank you.- v-tejrama1 month agoCommunity Support
Hi Venkatesh_ ,
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.
Thank you.