Supplies are limited. Contact info@espc.tech right away to save your spot before the conference sells out.
Get your discountScore big with last-minute savings on the final tickets to FabCon Vienna. Secure your discount
Hello, as you know, usage metrics are only made visible to F64 workspace Admins / Members Contributors, and not Viewers. However, I need to share usage metrics with *Viewers*.
In other words, my requirements are:
1) AAD group "Managers" must be able to see usage metrics for reports in the F64 workspace
2) AAD group "Managers" must never be granted edit permissions in the F64 workspace
How can I achieve this?
I've tried:
- Building my own usage metrics report by downloading the default one and editing it
- Using a custom Power BI REST API connector, but 'Report Users' falls under an (admin) category which my credentials cannot access
Any solutions gratefully received.
I would have thought this is a common requirement (business managers being able to see report usage data).
Solved! Go to Solution.
Hi, we've had to go with a more comprehensive workaround which is to use a notebook script to extract the data from the MS usage metrics dataset and save it to a SQL database, in order to break Microsoft's permission restrictions.
Using the previously suggested workaround worked for simple custom usage models but when adding a composite model, it only worked for some test users and not others, despite not finding any differences in any of their workspace permissions or AD group membership. It was not worth the time continuing to go into the weeds to resolve that, especially as MS's restriction on usage metrics visibility is artificial and non-adjustable by us, it was better to avoid it entirely.
Hi @than689,
Thank you for sharing the query in the Microsoft Community Forum. Also, thanks to @Tutu_in_YYC, @rohit1991, for those valuable inputs on this thread.
I completely understand the need for your "Managers" AAD group (who are workspace Viewers) to access usage metrics, while still maintaining strict control over edit permissions. here's a reliable approach that works within Power BI's current security model:
To share usage metrics with the "Managers" group without granting edit access, you can: Open the usage metrics report in the F64 workspace (as an Admin/Member). Use “File → Save a copy” to download the usage metrics report (this exports the dataset too). Open the .pbix in Power BI Desktop, customize it if needed. Publish this report to a separate workspace (e.g., “Usage Insights”). In that new workspace, add the “Managers” group as Viewers only. This way, they can access the report without any permissions to modify or publish content.
Note: Viewers cannot access usage metrics in the original workspace because the dataset isn't visible to them this is by design. But once you publish a copy elsewhere, the metrics dataset becomes like any other dataset, and you control who sees it.
Monitor usage metrics in workspaces (preview) - Power BI | Microsoft Learn
Also, I provided below is the solved thread which is useful:
Solved: Re: "View Usage Metrics Report" Option Not Visible... - Microsoft Fabric Community
Hope this helps clarify things and let me know what you find after giving these steps a try happy to help you investigate this further.
Thank you for using the Microsoft Fabric Community Forum.
Hi @than689,
Just checking in to see if the issue has been resolved on your end. If the earlier suggestions helped, that’s great to hear! And if you’re still facing challenges, feel free to share more details happy to assist further.
Thank you.
Hi, thank you for your helpful replies. I did not want to reply before fully investigating on my end. It seems publishing my existing custom metrics report to a new workspace did not solve the problem, but that could be a product of the way I set it up (it's a composite model where the usage data is a direct query to the original usage dataset, and other data is being imported). I've tried creating a simpler usage report from scratch and early signs are good - I will update in the next two days. Thanks
Hi @than689,
Thanks for getting back to us with the update and for taking the time to investigate further.
It is great to hear that your simpler usage report is showing promising results so far.
Since your current setup is a composite model (DirectQuery to the usage dataset + imported data), it is possible the original workspace configuration or dataset relationships were contributing to the issue. Rebuilding with a simpler structure is a good way to isolate the cause.
Please let us know how it goes over the next couple of days.
Thank you.
Hi @than689,
Just checking in to see if the issue has been resolved on your end. If the earlier suggestions helped, that’s great to hear! And if you’re still facing challenges, feel free to share more details happy to assist further.
Thank you.
Hi, we've had to go with a more comprehensive workaround which is to use a notebook script to extract the data from the MS usage metrics dataset and save it to a SQL database, in order to break Microsoft's permission restrictions.
Using the previously suggested workaround worked for simple custom usage models but when adding a composite model, it only worked for some test users and not others, despite not finding any differences in any of their workspace permissions or AD group membership. It was not worth the time continuing to go into the weeds to resolve that, especially as MS's restriction on usage metrics visibility is artificial and non-adjustable by us, it was better to avoid it entirely.
Hi @than689,
Thanks for sharing the details on how you have approached this. I understand why you opted for the notebook + SQL route, especially since the built-in permissions on usage metrics can feel restrictive in certain scenarios. The workaround you mentioned earlier can indeed cover simpler models, but as you saw, things get trickier with composite models and varying user contexts.
Now, the visibility rules for usage metrics are enforced by design and cannot be adjusted. That’s why your observation is correct. It is not something that can be fine-tuned in the service. The documentation here explains those limitations in more detail: Monitor report usage metrics - Power BI | Microsoft Learn
That said, your approach of externalizing the metrics into a SQL database is a solid way to bypass the limitation if you need more flexibility for broader access and modelling.
Hope this helps. If you have any doubts regarding this, please feel free to ask here. We will be happy to help.
Thank you for using the Microsoft Community Forum.
Hi @than689,
Just checking in to see if the issue has been resolved on your end. If the earlier suggestions helped, that’s great to hear! And if you’re still facing challenges, feel free to share more details happy to assist further.
Thank you.
Usage Metric report can be made visible to viewers. Just save a copy into the same workspace.
Hi @than689
You're absolutely right by default, usage metrics are only visible to Admins, Members, and Contributors, not Viewers. Since your “Managers” group must view usage metrics without being given edit permissions, here’s a clean workaround:
You can build a custom usage metrics report (which you already started doing) and publish it to a separate workspace where the AAD group “Managers” have Viewer access. In this setup, the report connects to the activity data source (like the Audit Logs or Office 365 usage data) using a service principal or a user with proper permissions. Then, just schedule a refresh and grant read-only access to that workspace. This way, they see the report without edit rights.
If needed, you can use Power BI REST API or Microsoft 365 Audit Logs (via Microsoft Purview) to get detailed usage data and feed it into that custom report.
Thanks - as I've just written in another reply, initially this didn't work for me but that was possibly due to the nature of my custom usage metrics and the data connection configurations. I've had one initial success using a *new* custom usage report in a separate workspace but will do some more investigation before confirming.
User | Count |
---|---|
32 | |
17 | |
11 | |
9 | |
8 |
User | Count |
---|---|
51 | |
31 | |
25 | |
17 | |
15 |