Jeder Cloud-Entwickler stolpert früher oder später über das gleiche Problem: Der Flow läuft quälend langsam, weil zu viele API-Aufrufe hintereinander geschaltet sind. Du möchtest Daten aus einer SharePoint-Liste ziehen und gleichzeitig Informationen aus einer verknüpften Personenspalte oder einer Nachschlage-Tabelle erhalten. Normalerweise würdest du eine Schleife bauen, die für jedes Element einen weiteren Abruf startet. Das ist jedoch der sicherste Weg, um dein API-Limit innerhalb von Minuten zu sprengen und die Performance in den Keller zu treiben. Die Lösung liegt in einer effizienten OData-Abfrage, genauer gesagt in der Funktion Expand Query In Power Automate, mit der du verwandte Datensätze in einem einzigen Rutsch abfragst.
Das Problem mit verschachtelten Schleifen
Wer mit Microsoft Power Automate arbeitet, gewöhnt sich schnell an das Prinzip der "Apply to each"-Schleife. Es wirkt intuitiv. Du holst eine Liste von Aufträgen ab. Danach gehst du jeden Auftrag durch, um den Namen des zuständigen Kunden aus einer anderen Tabelle zu fischen. In der Theorie funktioniert das wunderbar. In der Praxis erzeugst du bei 100 Aufträgen genau 101 Abrufe bei der Datenbank. Das kostet Zeit. Viel Zeit. Microsoft setzt zudem klare Grenzen bei den Anfragen pro Sekunde. Wenn dein Flow plötzlich hängen bleibt oder Fehlermeldungen wegen zu hoher Last ausspuckt, liegt das meist an diesem ineffizienten Design.
Echte Profis reduzieren die Anzahl der Operationen. Das spart nicht nur Ausführungszeit, sondern schont auch das Budget für die Lizenzierung. Jeder Schritt in einem Flow kostet Rechenleistung. Wenn du Daten direkt bei der Quelle zusammenführst, bevor sie überhaupt in deinen Workflow fließen, gewinnst du an Geschwindigkeit. Es geht darum, die Last auf den SQL-Server oder die Dataverse-Instanz zu verlagern. Diese Systeme sind für komplexe Abfragen optimiert. Ein Cloud-Flow ist es hingegen nicht. Er ist ein Orchestrierungswerkzeug. Er sollte die schwere Arbeit den Datenbanken überlassen.
Wie OData die Kommunikation steuert
Power Automate spricht meistens über das OData-Protokoll mit Datenquellen wie SharePoint oder Dataverse. Das ist ein offener Standard, der festlegt, wie man Daten filtert, sortiert und eben auch erweitert. Viele Anwender kennen die Filter-Abfragen. Sie schreiben dort einfache Logik wie "Status eq 'Abgeschlossen'". Aber die Erweiterung der Abfrage ist das Werkzeug, das den Unterschied zwischen einem Amateur und einem Experten macht. Es erlaubt dir, die Grenzen einer einzelnen Tabelle zu durchbrechen.
Stell dir vor, du hast eine Tabelle mit Projekten. Jedes Projekt hat einen Projektleiter. In der Haupttabelle steht aber nur die ID des Leiters. Ohne die richtige Technik müsstest du für jeden Namen separat anklopfen. Mit der richtigen Erweiterungslogik sagst du dem Server: Gib mir das Projekt und pack gleich die Details des Leiters mit in das Paket. Das Ergebnis ist eine saubere, flache Struktur, die du sofort weiterverarbeiten kannst.
Die technische Umsetzung von Expand Query In Power Automate
Wenn du in einer Aktion wie "Zeilen auflisten" aus der Dataverse-Gruppe arbeitest, findest du unter den erweiterten Optionen das Feld für die Erweiterung. Hier gibst du den Namen der Navigations-Eigenschaft an. Das ist oft der Punkt, an dem die meisten scheitern. Es ist nämlich nicht zwangsläufig der Anzeigename der Spalte, den du im Interface siehst. Du musst in die Metadaten schauen. Bei Dataverse ist das meist der logische Name der Beziehung. In SharePoint-Listen ist es oft der interne Name der Spalte.
Die Syntax für Dataverse
In Dataverse nutzt du meistens den logischen Namen der Spalte. Willst du zum Beispiel bei einer Aufgabe die Informationen des zugehörigen Kontakts mitladen, schreibst du einfach den Namen der Beziehung in das Feld. Spannend wird es, wenn du nur bestimmte Felder des verknüpften Objekts brauchst. Du willst ja nicht den kompletten Datensatz des Kontakts mit 200 Feldern ziehen, wenn du nur die E-Mail-Adresse benötigst. Hier hilft die Select-Anweisung innerhalb der Erweiterung. Du schreibst dann etwas wie "primarkontaktid($select=emailaddress1)". Das hält die Antwort klein und schnell.
Besonderheiten bei SharePoint
Bei SharePoint sieht die Sache etwas anders aus. Hier musst du oft den internen Namen der Spalte verwenden und zusätzlich angeben, welche Felder du daraus "expandieren" willst. Wenn deine Spalte "Kunde" heißt, musst du sicherstellen, dass dieser Name auch in der Systemkonfiguration so hinterlegt ist. Oft haben Spalten, die später umbenannt wurden, noch ihren alten, kryptischen Namen im Hintergrund. Ein Blick in die Listeneinstellungen in der URL-Leiste hilft dir, den echten Namen zu finden.
Wer tiefere Einblicke in die Architektur von Microsoft-Cloud-Lösungen sucht, findet auf den Seiten von Microsoft Learn detaillierte Dokumentationen zu den API-Limits und Best Practices. Es lohnt sich, diese technischen Grundlagen zu verstehen, bevor man komplexe Automatisierungen baut.
Warum Performance mehr als nur Geschwindigkeit ist
In großen Unternehmen bedeutet ein langsamer Flow mehr als nur eine kurze Wartezeit. Es kann bedeuten, dass Freigabeprozesse stocken oder Kunden zu spät informiert werden. Wenn ein Prozess 20 Minuten statt 20 Sekunden dauert, summiert sich das über das Jahr auf hunderte Stunden an verlorener Produktivität. Ein effizienter Einsatz von Abfragetechniken wie der Expand Query In Power Automate sorgt dafür, dass die Infrastruktur skaliert.
Ein weiterer Aspekt ist die Fehleranfälligkeit. Je mehr Schritte ein Flow hat, desto höher ist die Chance, dass einer davon fehlschlägt. Ein einziger Abruf, der alle Daten liefert, ist deutlich stabiler als 500 einzelne Abrufe in einer Schleife. Wenn beim 450. Abruf das Netzwerk kurz zuckt, bricht dein ganzer Flow ab. Bei einem kompakten Abruf hast du dieses Risiko massiv reduziert. Es ist schlichtweg saubereres Engineering.
Kostenkontrolle durch API-Optimierung
Microsoft berechnet die Nutzung seiner Dienste oft nach Kapazitätseinheiten oder API-Aufrufen. Wer ineffizient programmiert, zahlt am Ende drauf. Besonders im Kontext der Power Platform Lizenzen gibt es strikte Kontingente für Anfragen pro 24 Stunden. Ein schlecht optimierter Flow kann das Kontingent eines ganzen Nutzers aufzehren. Durch das Zusammenfassen von Anfragen bleibst du unter dem Radar dieser Limits. Das ist kein optionaler Luxus, sondern eine Notwendigkeit für den produktiven Einsatz im Betrieb.
Man kann das mit einem Einkauf im Supermarkt vergleichen. Du gehst ja auch nicht für jedes Produkt einzeln in den Laden, sondern schreibst eine Liste und erledigst alles in einem Gang. Genau das macht die Erweiterung der Abfrage für deine Flows. Sie schreibt die Einkaufsliste für den Server, damit dieser den Korb einmal vollpackt und dir übergibt.
Praktische Beispiele aus dem Arbeitsalltag
Schauen wir uns ein typisches Szenario an. Ein Unternehmen verwaltet seine Fuhrpark-Daten in Dataverse. Es gibt eine Tabelle für "Fahrzeuge" und eine für "Fahrer". In der Fahrzeug-Tabelle gibt es ein Nachschlagefeld zum Fahrer. Nun soll ein wöchentlicher Bericht erstellt werden, der alle Fahrzeuge auflistet und den Namen sowie die Telefonnummer des aktuellen Fahrers enthält.
Ohne Optimierung würde der Flow alle Fahrzeuge abrufen. Dann käme die berüchtigte Schleife. In der Schleife würde für jedes Fahrzeug die Aktion "Zeile nach ID abrufen" für den Fahrer stehen. Bei 500 Autos sind das 501 Aktionen. Mit der Erweiterung der Abfrage gibst du beim Auflisten der Fahrzeuge einfach an, dass der Fahrer-Datensatz mitgeladen werden soll. Der Flow führt genau eine Aktion aus. Die Daten des Fahrers stehen dir sofort als dynamische Inhalte zur Verfügung. Das spart Zeit, Nerven und Rechenpower.
Umgang mit komplexen Beziehungen
Manchmal reicht eine Ebene nicht aus. Du willst vielleicht das Fahrzeug, den Fahrer und die Abteilung des Fahrers wissen. Hier kommen verschachtelte Erweiterungen ins Spiel. Das Protokoll erlaubt es, über mehrere Stufen zu gehen. Du musst dabei jedoch vorsichtig sein. Jede Stufe erhöht die Komplexität der Datenbankabfrage. Wenn die Tabellen Millionen von Einträgen haben, kann eine zu tiefe Verschachtelung die Abfrage wiederum verlangsamen. Hier muss man die Balance finden. Meistens sind zwei Ebenen absolut unproblematisch und führen zu einem massiven Geschwindigkeitsvorteil.
Fehlerdiagnose bei OData-Fehlern
Wenn die Abfrage fehlschlägt, liegt es fast immer an einem Tippfehler im logischen Namen. Power Automate gibt dir dann oft eine Fehlermeldung wie "Resource not found" oder "Property not found". Mein Tipp: Nutze Tools wie den "FetchXML Builder" im XrmToolBox-Paket, wenn du mit Dataverse arbeitest. Damit kannst du die Abfrage visuell zusammenbauen und siehst sofort, wie die internen Namen lauten. Für SharePoint-Nutzer hilft ein einfacher Browser-Aufruf der API, um die Struktur der Daten zu prüfen.
Strategien für saubere Flows
Ein guter Entwickler dokumentiert, was er tut. Wenn du komplexe Erweiterungen in deine Aktionen einbaust, schreib einen Kommentar dazu. Erkläre kurz, welche Tabellen du verknüpfst. Das hilft Kollegen (oder dir selbst in sechs Monaten), den Flow zu verstehen. Ein weiterer Punkt ist das Error-Handling. Auch wenn eine optimierte Abfrage stabiler ist, solltest du prüfen, ob das Ergebnis leer ist. Nichts ist ärgerlicher als ein Flow, der abstürzt, weil er versucht, auf die E-Mail-Adresse eines Fahrers zuzugreifen, der im System gar nicht hinterlegt ist.
Prüfe regelmäßig die Ausführungszeiten deiner Flows im Power Platform Admin Center. Dort siehst du genau, welche Aktionen am längsten dauern. Wenn eine "Zeilen auflisten"-Aktion plötzlich Sekunden braucht, ist es Zeit, die Filter und Erweiterungen zu überprüfen. Oft helfen auch Indizes auf der Datenbankseite, um die Abfragen zu beschleunigen. Das ist vor allem bei SQL-Servern ein großes Thema. Eine Übersicht über die Governance und Verwaltung solcher Umgebungen bietet das Power Platform Admin Center.
Die Rolle von Select-Statements
Oft wird vergessen, dass "Expand" und "Select" Hand in Hand gehen. Wenn du eine Tabelle erweiterst, holst du standardmäßig alle Spalten der Zieltabelle. Das ist oft unnötiger Ballast. Nutze das Select-Feld, um nur die Spalten zu definieren, die du wirklich brauchst. Das reduziert die Payload, die über das Netzwerk geschickt wird. In einer Welt, in der Datenvolumen und Latenz eine Rolle spielen, ist das ein entscheidender Faktor. Weniger Daten bedeuten schnellere Deserialisierung im Flow-Motor.
Filterung auf erweiterten Feldern
Ein häufiger Wunsch ist es, die Hauptliste basierend auf Werten der erweiterten Tabelle zu filtern. Zum Beispiel: "Gib mir alle Fahrzeuge, deren Fahrer in der Abteilung Marketing arbeitet." Das ist mit OData möglich, erfordert aber eine präzise Syntax. Du musst den Pfad durch die Beziehung in deinem Filter-Ausdruck korrekt angeben. Viele scheitern hier und filtern stattdessen erst nach dem Abruf mit einer "Array filtern"-Aktion. Das ist jedoch wieder ineffizient. Je mehr du dem Server überlassen kannst, desto besser.
Die Grenzen der Technik
Natürlich ist diese Methode kein Allheilmittel. Es gibt Grenzen. SharePoint hat beispielsweise strikte Limits, wie viele Nachschlagefelder in einer einzigen Abfrage gleichzeitig erweitert werden dürfen. Meist liegt dieses Limit bei 12 Feldern. Wenn deine Liste extrem komplex ist, musst du deine Strategie überdenken. In solchen Fällen kann es sinnvoller sein, die Daten in eine effizientere Struktur zu überführen oder mit mehreren, gezielten Abfragen zu arbeiten statt mit einer riesigen, alles erschlagenden Anfrage.
Auch bei Dataverse gibt es Limits für die Tiefe der Verschachtelung. Man kann nicht unendlich viele Ebenen "nach oben" oder "nach unten" wandern. Wenn deine Datenstruktur so aussieht, dass du über fünf Ecken springen musst, ist vielleicht dein Datenmodell das Problem und nicht deine Abfragetechnik. Ein gutes relationales Design sollte solche extremen Pfade vermeiden.
Alternativen für Spezialfälle
Manchmal ist Power Automate einfach nicht das richtige Werkzeug für massive Datenmanipulationen. Wenn du Millionen von Datensätzen synchronisieren oder transformieren musst, schau dir Azure Data Factory oder Power Query an. Diese Tools sind speziell für ETL-Prozesse (Extract, Transform, Load) gebaut. Sie können mit großen Datenmengen weitaus effizienter umgehen als ein Flow, der für jedes Element eine Instanz startet.
Für die meisten geschäftlichen Anforderungen im Bereich der Prozessautomatisierung ist die hier beschriebene Methode jedoch genau richtig. Sie bietet die perfekte Mischung aus Einfachheit und Leistung. Man muss nur den Mut haben, die Standard-Schleifen-Logik zu verlassen und sich mit der OData-Syntax vertraut zu machen.
Nächste Schritte für deine Automatisierung
Jetzt ist es an der Zeit, das Gelernte in die Tat umzusetzen. Schau dir deine bestehenden Flows an. Such nach der "Apply to each"-Schleife, in der du Daten nachlädst. Das ist dein Startpunkt.
- Identifiziere die Beziehung: Finde heraus, wie die Tabellen verknüpft sind. Such den logischen Namen der Beziehung in den Metadaten von Dataverse oder den internen Namen in SharePoint.
- Teste die Abfrage: Nutze den Browser oder Tools wie Postman, um die OData-Abfrage manuell zu testen. Siehst du die gewünschten Daten im JSON-Ergebnis?
- Baue die Erweiterung ein: Geh in deinen Power Automate Flow und füge die Logik in das Feld für die Erweiterung ein.
- Optimiere mit Select: Reduziere die zurückgegebenen Felder auf das absolute Minimum. Deine Performance-Werte werden es dir danken.
- Entferne die Schleife: Jetzt kannst du die unnötigen "Nachladen"-Schritte innerhalb deiner Schleife löschen. Die Daten sind bereits da.
Ehrlich gesagt, am Anfang wirkt die Syntax etwas abschreckend. Aber sobald du den ersten Flow umgebaut hast und siehst, wie die Laufzeit von Minuten auf Sekunden schrumpft, willst du nie wieder anders arbeiten. Es ist ein echtes Erfolgserlebnis, wenn man ein System nicht nur zum Laufen bringt, sondern es wirklich meistert. Wer sich weiter in die Materie vertiefen möchte, findet auf der offiziellen OData-Website alle technischen Details zum Standard selbst.
Gutes Gelingen beim Optimieren deiner Prozesse. Es lohnt sich, hier einmal Zeit zu investieren, um langfristig stabilere und schnellere Lösungen zu bauen. Letztlich ist das Ziel jeder Automatisierung, uns die Arbeit zu erleichtern, nicht uns mit langsamen Abläufen und API-Fehlern zu frustrieren. Wer die Logik hinter der Datenabfrage versteht, baut Lösungen, die auch bei steigenden Nutzerzahlen nicht in die Knie gehen.
