Power BI Microsoft Graph API: Konzept, Setup und Best Practices

Definition

Die Microsoft Graph API ist eine REST-API für den einheitlichen Zugriff auf Daten und Funktionen aus Microsoft 365 und Azure Active Directory (Entra ID). Sie ist keine Power-BI-Datenquelle „out of the box“, sondern erfordert App-Registrierung, OAuth 2.0 und Berechtigungen, bevor Daten in Power Query abgefragt werden können.

Einleitung

Wenn User- und Geräteinformationen, Gruppen oder Lizenzdaten heute in Excel gepflegt werden, kostet das Zeit und erzeugt Diskussionen über „welche Liste stimmt“. Mit dem Setup „power bi microsoft graph api“ holst du diese Daten automatisiert ins Reporting: planbar aktualisiert, nachvollziehbar berechtigt und direkt nutzbar für Dashboards, Audits oder Self-Service-Analysen in Power BI.

Welche Daten bringen in Power BI wirklich Mehrwert?

Graph-Daten sind dann stark, wenn sie Prozesse absichern oder Transparenz schaffen, die sonst manuell entsteht. Typische Beispiele: IT will Geräte, Compliance-Status oder Rollen sichtbar machen; Fachbereiche brauchen eine saubere Zuordnung von Personen zu Bereichen/Standorten für verantwortliche KPIs.

• Identitäten: User, Gruppen, Rollen (z. B. für Verantwortlichkeiten und Filter)
• Geräte: registrierte Devices und IDs (z. B. für Inventar und Compliance-Übersichten)
• Organisation: Abteilungen, Manager-Beziehungen (für Org-Drilldowns)

Wichtig: Das werden meistens Dimensionstabellen, die andere Fakten (z. B. Tickets, Kosten, Projekte) erst analysierbar machen.

Voraussetzungen: Zugriff, App-Registrierung, Rollen

Für Graph-Zugriffe braucht es eine Azure AD App Registration und einen Service Principal. Entscheidend ist die Frage „delegated vs. application permissions“: In Power BI-Refresh-Szenarien ist „Application“ häufig sinnvoller, weil der Refresh nicht an eine einzelne Person gebunden sein soll.

Minimaler Setup-Plan

• App in „Azure AD App Registration“ anlegen, Tenant-ID und Client-ID notieren
• API Permissions für Microsoft Graph wählen und Admin Consent erteilen (wenn nötig)
• Client Secret oder Zertifikat erstellen (für den OAuth 2.0-Client-Credentials-Flow)

Scopes/Berechtigungen sollten so klein wie möglich sein. Ein häufiges Muster ist: erst nur „Users.Read.All“ testen, später gezielt erweitern.

Authentifizierung: OAuth 2.0-Flow und Token-Lifecycle

Power Query ruft Graph-Endpunkte mit einem Bearer Token auf. Dieses Token kommt aus einem POST an den Token-Endpunkt von Microsoft Identity (OAuth 2.0). Praktisch relevant sind drei Dinge: Ablaufzeit des Tokens, sichere Geheimnisverwaltung und der Unterschied zwischen interaktivem Test (Desktop) und automatisiertem Refresh (Service).

• Token läuft ab: Lösung ist ein erneuter Token-Abruf im Refresh, nicht „Token speichern“
• Secrets schützen: keine Secrets im Klartext in Dateien oder im Bericht verteilen
• Consent/Policies: Conditional Access kann Service-Principals blocken, wenn falsch konfiguriert

Wenn Security streng ist, lohnt eine frühe Abstimmung mit IT-Security, weil das später viel Debug-Zeit spart.

Schritt-für-Schritt: Datenquelle in Power Query anbinden

Für Graph gibt es zwei gängige Wege: (1) Power Query mit Web-Requests (Web.Contents) oder (2) ein Custom Data Connector für wiederverwendbare Authentifizierung und saubere Parameter. Für ein erstes MVP reicht meist Power Query; für Betrieb und Skalierung ist ein Connector oft die bessere Investition.

Vorgehen (MVP mit Power Query)

• Token per POST holen (Tenant, Client-ID, Secret, Scope), Ergebnis ist ein Access Token
• Graph-Endpoint per GET abfragen, Header „Authorization: Bearer …“ setzen
• JSON in Tabellen transformieren und in ein starres Schema überführen

Die Basis-URL ist typischerweise https://graph.microsoft.com/v1.0. Für große Datenmengen muss Pagination („@odata.nextLink“) verarbeitet werden, sonst fehlen Datensätze.

Beispiel-Endpunkte und typische Query-Muster

Als Startpunkt eignen sich einfache, breit nutzbare Ressourcen. Beispielabfragen sind bewusst simpel, weil der Hauptwert in der Wiederholbarkeit (Refresh) und Verknüpfung im Modell liegt.

• GET /v1.0/users (Userliste, z. B. mit displayName, mail, department)
• GET /v1.0/devices (Geräte inkl. Device IDs, je nach Berechtigung)
• GET /v1.0/groups (Gruppen für Berechtigungs- oder Team-Sichten)

Für Entwicklung und Validierung ist Graph Explorer hilfreich, weil man dort schnell sieht, ob das Problem an Permissions oder an der Query liegt.

Datenmodellierung in Power BI: so wird es reportbar

Graph liefert oft „breite“ JSON-Strukturen. Für Power BI braucht es stabile Schlüssel, klare Dimensionen und möglichst wenig Mehrdeutigkeit. Der Nutzen: Fachbereiche können später auf saubere, eindeutige Tabellen zugreifen und direkt Visuals bauen, ohne ständig an der Datenbeschaffung zu schrauben.

• Users als Dimension: UserId/UPN als Schlüssel, Abteilung/Standort als Attribute
• Devices als Dimension: DeviceId als Schlüssel, Status/OS als Attribute
• Beziehungen: 1:n zu Fakten (z. B. Tickets, Kosten, Schulungen), nicht umgekehrt

Wenn ein Feld sich über Zeit ändert (Abteilung, Manager), muss entschieden werden, ob eine Historisierung nötig ist oder ob „aktueller Stand“ reicht.

Sicherheit, Berechtigungen und typische Fehler

Die häufigsten Issues sind keine „Power BI Probleme“, sondern Berechtigungs- oder Policy-Themen im Directory. Eine saubere Rollen- und Permission-Strategie reduziert Risiko und Lernkurve massiv.

• 401/403: Token fehlt, abgelaufen oder Scope/Berechtigung nicht ausreichend
• Admin Consent fehlt: Permission ist gesetzt, aber nicht tenantweit freigegeben
• Throttling/Limits: zu viele Calls, Pagination ignoriert oder zu große Abfragen

Best Practice ist, Queries zu bündeln, nur benötigte Felder zu ziehen und Refresh-Frequenz passend zum Use Case zu wählen (Governance-Daten ändern sich selten minütlich).

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn (1) OAuth 2.0 und Service-Principal-Setup blockieren, (2) Security/IT-Policies (Conditional Access, Consent-Prozesse) unklar sind oder (3) ihr das Ganze betriebsfest braucht: wiederverwendbarer Connector, dokumentiertes Berechtigungskonzept, sauberes Datenmodell und belastbarer Refresh.

Dann sparst du typischerweise nicht „ein bisschen Bastelzeit“, sondern verhinderst ein Setup, das nach dem ersten Token-Problem oder Policy-Change wieder auseinanderfällt.