Power BI Update April 2026

Power BI REST API - Admin Get Activity Events

In vielen Power‑BI‑Projekten taucht früher oder später dieselbe Frage auf:

„Welche Reports werden eigentlich wirklich genutzt – und von wem?“

Gerade bei einer wachsenden Anzahl an Workspaces, Reports und Datasets wird es schnell unübersichtlich. Microsoft stellt dafür allerdings ein hilfreiches Werkzeug bereit: die Power BI Activity Events API. Sie liefert detaillierte Informationen darüber, was im Tenant passiert – von Report-Aufrufen über Refreshes bis hin zu Exporten.

Wir haben uns angesehen, wie man diese Daten möglichst unkompliziert automatisiert abrufen, persistieren und auswerten kann. Das Ergebnis ist ein Workflow, der per Notebook die Activity Events lädt, im Lakehouse speichert und anschließend im Semantic Model für ein Report nutzbar macht.

In diesem Blog zeigen wir, wie der Ansatz funktioniert, welche Vorteile er bringt und warum er sich ideal für Analyse und Governance eignet.

Microsoft stellt mit der Get Activity Events API eine umfassende Möglichkeit bereit, um tenant‑weit Power‑BI‑Aktivitäten auszulesen.

Unter anderem:

• welche Reports angesehen wurden
• welche Benutzer aktiv sind
• welche Workspaces besonders stark genutzt werden
• wann Dataset‑ und Model‑Refreshes ausgeführt wurden
• ob Operationen erfolgreich oder fehlerhaft waren
• ob Inhalte exportiert, geteilt oder gelöscht wurden

Die API liefert Ereignisse für einen Zeitraum von bis zu 28 Tagen rückwirkend. Der eigentliche Mehrwert entsteht jedoch, wenn diese Daten regelmäßig abgerufen und persistiert werden. Durch das Speichern der Activity Events – z. B. in einem Lakehouse – lassen sich Aktivitäten historisieren und auch über längere Zeiträume hinweg analysieren.

Workflow

Um die Activity Events dauerhaft nutzbar zu machen, haben wir einen kompakten, aber effektiven Workflow innerhalb von Microsoft Fabric aufgebaut.

Im ersten Schritt ruft ein Notebook die Activity Events API für einen definierten Zeitraum ab. Die zurückgelieferten JSON‑Events werden anschließend verarbeitet und als Delta Tabelle gespeichert. Als zentrale Ablage dient ein Lakehouse.

Damit dieser Prozess nicht manuell angestoßen werden muss, wird das Notebook zeitgesteuert ausgeführt. Typischerweise erfolgt die Ausführung einmal täglich und lädt die Activity Events des Vortags.

In Kombination mit einem darauf aufbauenden Semantic Model entsteht eine vollständig automatisierte Kette:

• API‑Abruf
• Speicherung im Lakehouse
• Aktualisierung des Modells
• Bereitstellung der Daten für ein Report

Gerade in Verbindung mit Direct Lake bleiben die Daten im Semantic Model automatisch aktuell, ohne dass ein klassischer Import‑Refresh notwendig ist. Insgesamt entsteht so ein vollständig automatisierter Workflow – von der API bis zum fertigen Usage‑Report.

Authentifizierung & Sicherheit: Zugriff per Service Principal

Die API wird per OAuth 2.0 authentifiziert – also über ein sicheres Access Token, das über Azure Active Directory (Microsoft Entra ID) ausgestellt wird. Für die Nutzung ist eine Azure App Registration erforderlich, die als Service Principal im Power‑BI‑Tenant verwendet wird.

Da es sich bei der Get Activity Events API um eine Admin‑API handelt, benötigt der Service Principal explizite Administratorrechte im Power BI Tenant.

Konkret:

• Der Service Principal muss im Power BI Admin Portal für die Nutzung der Admin APIs freigegeben sein („Allow service principals to use Power BI APIs“).
• Zusätzlich muss der Zugriff auf Read‑only Admin APIs erlaubt sein, da Activity Events tenant‑weit ausgelesen werden.
• Alternativ kann der Service Principal einer der folgenden Rollen zugewiesen bekommen:
  • Power BI Administrator
  • Fabric Administrator

Der Service Principal übernimmt dabei die Rolle eines technischen Benutzers, der berechtigt ist, die Activity Events API aufzurufen und die Daten automatisiert weiterzuverarbeiten.