Almanac
Microsoft/power-biPower Platform

Consultant KB for Microsoft Power BI: semantic models, DAX and modelling, Power Query and dataflows, reports and visuals, the service and workspaces, capacity and performance, embedding and integration, governance and security, ALM and deployment, and licensing, plus cross-cutting decision guides. Scoped to Power BI, with Microsoft Fabric covered where it touches Power BI directly. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power BI release plans, docs repo and product blog, plus the author's own consultant notes.

feature-audit-logs-and-activity.mdv1 · history
CurrentApplies to ServiceUpdated last monthSource Microsoft Learn

What it does

Records who did what to which item. Two front doors onto broadly the same events: the Microsoft Purview audit log, searched in the Purview portal or through Exchange Online PowerShell, and the Power BI activity log, pulled programmatically with the Get-PowerBIActivityEvent cmdlet or the Get Activity Events admin REST API.

Key facts

  • The Power BI activity log holds a maximum of 28 days. You can't request a date earlier than 28 days before today. If you want history, you export and store it yourself.
  • The Get-PowerBIActivityEvent cmdlet retrieves one day per call. The underlying REST API only takes one hour per request, and you have to handle continuation tokens and token expiry yourself — which is why the cmdlet is usually the better choice.
  • Get Activity Events is limited to 200 requests per hour. Loop carelessly across days and activity types and you'll be throttled.
  • Retrieving activity log data is itself a logged operation (ExportActivityEvents), so admin activity shows up in your own extracts.
  • Timestamps are always UTC. Converting JSON to a PowerShell object silently converts times to local, which is how audit analyses end up an hour out.
  • Purview audit access needs the Audit Logs role in Exchange Online; by default Compliance Management and Organization Management have it. Activity log access needs the Fabric administrator role.
  • Purview audit retention is governed by Microsoft Purview retention policies, not by Power BI. Treat the 28-day activity log figure and the Purview retention figure as separate numbers.
  • Event payloads differ by event type and change over time as Power BI evolves. Extract raw JSON rather than parsing on the way out.
  • Sensitivity label IDs appear on relevant events, so you can report on consumption of labelled content.
  • Where capacity ID and name are missing from audit entries, get them from the Fabric Capacity Metrics app.

When to use / skip

Anyone running Power BI seriously needs a daily export job, and the reason is simple: 28 days is not an audit trail, it's a rolling window. Set up the extract before anybody asks for it, because the day someone asks "who saw that report in March" is the day you find out you don't have March. Skip building a full auditing solution when the client's questions are all about adoption rather than compliance — the feature usage and adoption report in the admin monitoring workspace covers those without any code.

Configuration decisions

  • Where extracted activity data lands and how long it's kept, which should follow the client's records retention policy rather than a technical default.
  • Whether the extract runs under a service principal, which is what Microsoft recommends for unattended scheduled scripts.
  • Extract cadence, and whether you pull yesterday's complete day rather than today's partial one.
  • Whether you extract raw JSON and transform later, or filter on the way out — the first is more resilient to schema change.
  • Which questions the client actually needs answered, since that determines whether you need the activity log, Purview audit, the scanner API, or all three joined together.

Gotchas

  • Extracting the current day gives you a partial day. Always work one day back so each file holds a full 24 hours.
  • Filtering results after retrieval in a large tenant is slow and burns your 200-requests-per-hour budget. Pull once, query many times.
  • UpdateApp events only record what changed, not the full permission set. Reconstructing app permissions from the activity log gives you an incomplete picture — use Get App Users as Admin for a snapshot instead.
  • There's a lag before events are retrievable. Building a near-real-time alert on the activity log is a frustrating exercise.
  • The response shape varies by event, and even within an event type. Scripts that assume a fixed schema break quietly on new event variants.
  • What you can genuinely answer is narrower than clients assume: who opened a report, who shared it and with whom, who exported, who changed a label, who created or updated an app. What you cannot answer is which rows or figures a user actually looked at.

Consultant notes

  • Day one deliverable: a scheduled export of the activity log to durable storage. It's an hour's work and it's the thing clients are most grateful for eighteen months later.
  • Set expectations about what "audit" means here. Executives often hear "we can see who saw the salary figures" — you can see who opened the report, not what they read.
  • Point the client at Microsoft's tenant-level auditing planning guidance rather than improvising a design. It covers the decisions in an order that works.
  • Use a service principal for the scheduled job and document the credential rotation. An audit pipeline that stops because a password expired is embarrassing in exactly the meeting where it matters.

Worth checking again if the 28-day activity log window changes, or if Purview audit retention shifts under the client's licensing.

Was this accurate?