The Power BI Activity Log - Finding Out What People Actually Do With Your Reports

Here's a question that stumps most Power BI admins the first time a manager asks it: "Which of our reports does anyone actually use?" It sounds like it should be a dashboard somewhere. It isn't. The answer lives in the Power BI activity log, and getting at it takes a bit more effort than most people expect.

We see this on nearly every Power BI governance engagement we run for Australian organisations. Someone has spent three years letting analysts publish whatever they like, the tenant now has 400 workspaces and 2,000 reports, and leadership wants to know what can be deleted, what needs to be certified, and whether the Premium capacity they're paying for is earning its keep. Every one of those questions runs through the activity log. So does the awkward compliance question that turns up after an incident: "Who exported that customer data to Excel, and when?"

What the activity log actually is

The activity log records user and admin activities across your Power BI tenant. Every report view, every dashboard share, every export to Excel, every dataset refresh, every workspace creation, every app install. Each event comes back as a JSON record with the user, the timestamp, the activity type, and the object it happened to.

There are two ways to get at this data, and the distinction matters because they have different permission requirements and different retention.

The first is the Power BI activity log itself, accessed through the admin REST API (the ActivityEvents endpoint) or the Get-PowerBIActivityEvent cmdlet in the Power BI Management PowerShell module. This is Power BI events only, and you need to be a Fabric administrator (or use a service principal with the right setup) to call it. No Microsoft 365 audit permissions required, which is the main reason it exists - the BI team can pull their own usage data without begging the security team for access to the wider audit infrastructure.

The second is the Microsoft 365 unified audit log through Purview, which includes Power BI events alongside everything else happening in your Microsoft 365 estate. Longer retention depending on your licensing, but access is controlled by the compliance side of the house, and in most organisations we work with, the BI team doesn't have it and won't get it quickly.

For day-to-day BI governance, the Power BI activity log is the one you want. Microsoft's guidance article on accessing it is genuinely good and worth reading in full, which is not something I say about every page in the Power BI docs.

The 30-day catch

This is the part that bites people, so I'll put it up front: the activity log only holds 30 days of history. Not 90. Not a year. Thirty days, on a rolling window.

If you don't have a process extracting and storing that data somewhere, it's gone. I've sat in more than one meeting where a client wanted twelve months of adoption trends to justify a capacity purchase and we had to break the news that the data simply doesn't exist because nobody was collecting it. The report they wanted in July needed a decision someone should have made the previous August.

So the first practical step for any organisation taking Power BI seriously: set up a scheduled job that pulls the activity log daily and lands it somewhere durable. A Fabric lakehouse is the natural home these days, though we've built perfectly serviceable versions landing JSON files in a storage account with a Data Factory pipeline on a schedule. The job itself is not complicated. The API returns one day of data at a time (in UTC, which trips up Australian teams doing date maths - your business day spans two UTC dates), and you page through continuation tokens until you're done. A service principal with the right tenant settings enabled means no user credentials in the pipeline.

Do this before you need it. It's a day of work, maybe two with proper error handling, and it turns a 30-day window into a permanent record.

What we actually use it for

Raw activity events are just rows. The value shows up when you point them at real decisions. A few patterns from client work:

Killing dead reports. Join the activity log against the list of reports from the admin API (or the scanner APIs) and you'll typically find that somewhere between a third and half of the reports in a mature tenant have had zero views in the last quarter. That's not a criticism of anyone - it's the natural sediment of years of ad hoc publishing. But every dead report is something a new starter might find in search, trust, and make a decision from. We've run cleanup exercises off this data that deleted hundreds of reports, and the pushback is always smaller than the client fears because the log proves nobody was looking.

Adoption tracking that isn't vibes. Usage metrics reports in the service give you per-report views, but the activity log gives you the tenant-wide picture: distinct users per week, which departments are actually opening things, whether the expensive dashboard the executive sponsor demanded gets opened by anyone other than the executive sponsor. When a client asks whether their Power BI rollout is working, this is the evidence.

Security and audit questions. ExportActivity events tell you who pulled data out of a report and into a file. ShareReport and ShareDashboard events tell you when something got shared more widely than intended. When a client in financial services had to answer a regulator's question about who had accessed a particular report over a given fortnight, the answer took twenty minutes because the extraction pipeline had been running for a year. Without it, the answer would have been "we don't know", which is not a sentence you want to say to APRA.

Capacity and licensing decisions. Before renewing or resizing Premium or Fabric capacity, look at what's actually being used and by whom. We've seen clients about to buy more capacity when the log showed the pressure was three badly-built reports refreshing hourly for an audience of nobody.

The rough edges

A few honest warnings from having done this repeatedly.

The event schema is inconsistent. Different activity types carry different fields, fields appear and disappear as Microsoft adds features, and you will find events with properties that are documented nowhere. Land the raw JSON and parse what you need downstream rather than forcing everything through a rigid schema at ingestion - future you will be grateful when a new event type shows up.

Some events are noisy and some are missing. Report views via apps, embedded scenarios and subscriptions all show up slightly differently, and reconciling "views" across those paths takes care. And the log tells you an activity happened, not how long anyone spent or whether the report was useful. It measures opens, not outcomes.

Naming has shifted with the Fabric transition. What was Power BI admin territory is increasingly Fabric admin territory, the portal keeps moving settings around, and older blog posts reference cmdlets and portal paths that have since been renamed. Anchor on the current Microsoft docs, not on a 2023 tutorial.

Where to start

If you're a Power BI admin and you've never touched this: install the Power BI Management module, run Get-PowerBIActivityEvent for yesterday's date, and look at what comes back. That's ten minutes and it makes everything above concrete. Then build the daily extraction job, because the 30-day clock is running whether you're collecting or not.

If you want the full setup - extraction pipeline, a curated model over the top, and the governance conversations about what to do with the findings - this is bread-and-butter work for our Power BI consulting team. It usually pairs with broader platform work our Microsoft Fabric consultants handle, since the natural home for this data is a Fabric lakehouse feeding the same reporting estate it describes. And if the underlying question is really "how do we get better decisions out of our data", that's the wider business intelligence conversation, and the activity log is just the first honest dataset in it.

Either way, start collecting. The most common regret we hear about the activity log isn't about how it was set up. It's about the year of history that vanished before anyone thought to keep it.