SharePoint-Aufgaben mit Power Automate verbinden: Trigger, Status und saubere Übergaben

Wie verbindet man SharePoint-Aufgaben mit Power Automate so, dass Statuswechsel stabile Folgeprozesse auslösen und kein Trigger doppelt ausgeführt wird? Die Verbindung zwischen SharePoint-Aufgabenlisten und Power Automate klingt technisch einfach. In der Praxis scheitern viele Implementierungen an einem oder mehreren der gleichen Probleme: Flows werden doppelt ausgelöst, Statusänderungen lösen Schleifen aus, Berechtigungen fehlen zur Laufzeit, oder Folgeprozesse laufen an, obwohl die Ausgangsbedingung gar nicht erfüllt ist.

Dieser Ratgeber zeigt, wie SharePoint-Aufgaben mit Power Automate so verbunden werden, dass Trigger sauber definiert sind, Statuswechsel zuverlässig erkannt werden und die Übergabe an Folgeprozesse kontrolliert stattfindet. Für die vorgelagerte Prozessentscheidung ordnet Power Automate SharePoint Prozesse ein, wann Aufgabenlisten, Freigaben und Statusfelder zusammengehören.

Typische Muster für Aufgaben in SharePoint

In SharePoint können Aufgaben auf verschiedenen Ebenen entstehen. Das Grundmuster ist eine Liste – entweder die klassische SharePoint-Aufgabenliste oder eine selbst angelegte Liste mit eigenen Feldern. Beide können als Ausgangspunkt für Power-Automate-Flows genutzt werden.

SharePoint-Aufgabenliste versus benutzerdefinierte Liste

Die eingebaute SharePoint-Aufgabenliste bringt ein vordefiniertes Datenmodell mit Feldern wie „Zugewiesen an“, „Fälligkeit“, „% Erledigt“ und „Status“. Sie ist für viele einfache Aufgaben-Workflows ein guter Ausgangspunkt, hat aber Einschränkungen: Das Status-Feld hat feste Werte (Nicht begonnen, Abgeschlossen, Zurückgestellt etc.) und lässt sich nur eingeschränkt anpassen.

Eine benutzerdefinierte SharePoint-Liste ist flexibler. Eigene Statuswerte, eigene Felder für Prozessschritte, Prioritäten, Verknüpfungen zu Dokumenten oder Projektlisten lassen sich gezielt einbauen. Für komplexere Workflows ist eine benutzerdefinierte Liste meist die bessere Wahl.

Typische Aufgaben-Workflows

In der Praxis begegnen folgende Muster regelmäßig:

• Aufgabenzuweisung: Eine neue Aufgabe wird erstellt, eine Person wird zugewiesen, diese Person bekommt eine Benachrichtigung.
• Statuswechsel als Trigger: Wenn eine Aufgabe auf „In Bearbeitung“ oder „Erledigt“ gesetzt wird, soll eine Aktion folgen, etwa eine Benachrichtigung, eine Folgeaufgabe oder ein Eintrag in einem anderen System.
• Eskalation bei Fristüberschreitung: Wenn eine Aufgabe zum Fälligkeitsdatum nicht abgeschlossen ist, wird der Verantwortliche erinnert und optional der Vorgesetzte informiert.
• Prozesskette: Eine abgeschlossene Aufgabe löst die Erstellung der nächsten Aufgabe im Prozessschritt aus.

Alle diese Muster haben jeweils eigene Trigger-Anforderungen, die sorgfältig ausgewählt werden müssen.

Trigger-Auswahl: erstellt, geändert, Statuswechsel, manuell

Der richtige Trigger ist der wichtigste Entscheidungspunkt beim Aufbau eines Aufgaben-Flows. Power Automate bietet für SharePoint-Listen drei relevante Standard-Trigger:

„Wenn ein Element erstellt wird“

Dieser Trigger löst aus, wenn ein neuer Listeneintrag angelegt wird. Er eignet sich für:

• Benachrichtigungen bei neuer Aufgabenzuweisung,
• automatische Vorbefüllung von Feldern,
• Anlegen von Unteraufgaben zu einer neu erstellten Hauptaufgabe.

Was dieser Trigger nicht erkennt: spätere Änderungen am Eintrag. Er wird genau einmal pro Eintrag ausgelöst, zum Zeitpunkt der Erstellung.

„Wenn ein Element geändert wird“

Dieser Trigger löst bei jeder Änderung an einem Listeneintrag aus, unabhängig davon, welches Feld geändert wurde. Das ist sein größtes Problem: Er reagiert auf jede Feldänderung, auch auf technisch automatisch erzeugte Änderungen wie das Setzen eines Zeitstempels durch einen anderen Flow.

Ohne eine explizite Bedingung im Flow-Body, die prüft, ob sich das relevante Feld tatsächlich geändert hat, entsteht leicht eine Dauerschleife.

Statuswechsel als gezielter Auslöser

Power Automate bietet keinen eigenen „Status wurde geändert“-Trigger. Stattdessen wird der „Wenn ein Element geändert wird“-Trigger mit einer Bedingung kombiniert:

1. Der Trigger löst bei jeder Änderung aus.
2. Im Flow folgt eine Bedingung: Ist der neue Wert des Statusfeldes „Erledigt“?
3. Nur wenn diese Bedingung wahr ist, wird der restliche Flow ausgeführt.

Das allein reicht jedoch nicht aus, um Mehrfachausführungen zu verhindern. Wenn ein weiterer Flow dasselbe Element aktualisiert, löst das erneut den Trigger aus. Die Lösung dafür ist ein Prüffeld.

Prüffeld für eine kontrollierte Einmalbedingung

Eine bewährte Methode ist ein Feld wie „FlowAusgelöst“ (Typ: Ja/Nein) in der Liste. Der Flow prüft zu Beginn, ob dieses Feld noch auf „Nein“ steht. Wenn ja, wird das Feld sofort auf „Ja“ gesetzt, bevor die eigentlichen Flow-Aktionen ausgeführt werden. So wird sichergestellt, dass jede Statusänderung nur einmal verarbeitet wird, auch wenn der Trigger mehrfach feuert.

Manueller Trigger und Button-Flows

Für Aufgaben, die bewusst durch eine manuelle Aktion in Gang gesetzt werden sollen, eignen sich entweder ein Power-Apps-Aufruf oder der Button-Trigger in Power Automate. Button-Flows können Benutzereingaben entgegennehmen und werden nicht automatisch ausgelöst, was Schleifen und unerwartete Mehrfachausführungen verhindert.

Aufgaben erzeugen, aktualisieren und an Folgeprozesse übergeben

Aufgabe automatisch erstellen

Die Power-Automate-Aktion „Element erstellen“ (Create item) auf einer SharePoint-Liste erstellt einen neuen Eintrag. Beim Aufbau einer Prozesskette, in der abgeschlossene Aufgaben neue Aufgaben erzeugen, sind folgende Felder besonders wichtig:

• Titel: Eindeutig und prozessschritt-spezifisch formuliert, damit Empfänger sofort wissen, was zu tun ist.
• Zugewiesen an: Als E-Mail-Adresse oder als UPN-Wert der Person. Personenspalten in SharePoint erwarten ein spezifisches Format – häufigster Fehler ist die Übergabe eines reinen Namens statt einer gültigen E-Mail-Adresse oder Claims-ID.
• Fälligkeit: Als UTC-Datum. Wird das Datum lokal erzeugt, muss die Zeitzone des Tenants berücksichtigt werden, um Datumsverschiebungen zu vermeiden.
• Status: Einen definierten Ausgangswert setzen, typischerweise „Nicht begonnen“.

Aufgabe aktualisieren

Die Aktion „Element aktualisieren“ (Update item) benötigt zwingend die ID des Eintrags. Diese kann entweder aus dem Trigger-Output (bei Änderungen) oder aus einer vorherigen „Elemente abrufen“-Aktion stammen.

Wichtig: Die Aktion „Element aktualisieren“ verlangt bei Pflichtfeldern eine vollständige und saubere Zuordnung. Werden dynamische Werte leer übergeben oder Pflichtfelder im Flow nicht kontrolliert gemappt, können vorhandene Werte ungewollt überschrieben oder Validierungen verletzt werden. Um gezielt nur ein einzelnes Feld zu ändern, kann die REST-API-Aktion mit einem PATCH-Aufruf sinnvoller sein.

Übergabe an Folgeprozesse

Wenn eine abgeschlossene Aufgabe einen Folgeprozess auslöst, muss die Übergabe sauber sein. Folgende Felder sind für eine zuverlässige Übergabe wichtig:

• Aufgaben-ID: Als eindeutiger Schlüssel für Rückreferenzen im Folgesystem.
• Status: Der aktuelle, bereits geprüfte Statuswert.
• Zugewiesene Person: Für Benachrichtigungen, Folgeaufgaben-Zuweisungen oder Berechtigungsvergaben.
• Übergeordnete Referenz: Wenn Aufgaben in einer Hierarchie stehen, eine Referenz auf das übergeordnete Objekt (z.B. Projekt-ID, Anforderungs-ID).

Schleifen, Dubletten und Endlos-Trigger verhindern

Dies ist der technisch kritischste Abschnitt. Viele Aufgaben-Workflows in SharePoint und Power Automate scheitern nicht an falscher Logik, sondern an Trigger-Schleifen oder Mehrfachausführungen.

Ursachen für Schleifen

Eine Schleife entsteht typischerweise so:

1. Flow A wird ausgelöst, wenn sich Eintrag X ändert.
2. Flow A ändert Eintrag X (z.B. setzt ein Statusfeld).
3. Durch diese Änderung wird Flow A erneut ausgelöst.
4. Der Zyklus beginnt von vorne.

Schleifen unterbrechen mit Bedingungen

Die zuverlässigste Methode ist eine kombinierte Bedingung zu Beginn des Flows, die mehrere Kriterien prüft:

• Hat sich das relevante Feld geändert (neuer Wert ≠ alter Wert)?
• Ist das Prüffeld noch nicht gesetzt?
• Hat der Auslöser-Account nicht die „Automatisierungs-E-Mail“ (um Flow-on-Flow-Triggerketten zu erkennen)?

Wenn eine dieser Bedingungen nicht erfüllt ist, beendet der Flow ohne Aktion.

„Trigger conditions“ nutzen

Power Automate bietet eine Funktion namens Trigger Conditions (Ausführungsbedingungen), mit der noch vor dem Start des eigentlichen Flow-Bodies geprüft wird, ob bestimmte Bedingungen erfüllt sind. Damit lassen sich viele unnötige Trigger-Aktivierungen schon in der Konfiguration abfangen:

@equals(triggerBody()?['Status']?['Value'], 'Erledigt')

Diese Bedingung sorgt dafür, dass der Flow nur dann überhaupt startet, wenn das Statusfeld „Erledigt“ ist. Alle anderen Änderungen ignoriert Power Automate vollständig, ohne den Flow-Body zu starten.

Parallelitätsprobleme bei gleichzeitigen Änderungen

Wenn viele Benutzer gleichzeitig Aufgaben in einer Liste aktualisieren, kann es vorkommen, dass derselbe Flow für dasselbe Element mehrmals gleichzeitig gestartet wird. Die Einstellung Parallelitätskontrolle im Trigger des Flows begrenzt die gleichzeitige Ausführung. Für Workflows, die denselben Eintrag aktualisieren, sollte die Parallelitätskontrolle auf 1 gesetzt werden.

Typische Fehler bei Berechtigungen, Parallelität und Triggerbedingungen

Fehlende Berechtigungen bei Laufzeit

Power Automate führt Flows standardmäßig im Kontext des Flow-Erstellers aus. Wenn der Flow-Ersteller keine Schreibrechte auf die Zieldaten hat, schlägt die Aktion fehl. In Unternehmensumgebungen sollte ein dediziertes Dienstkonto oder ein Connection Account mit den nötigen Rechten verwendet werden.

Bei Flows, die „als Benutzer“ ausgeführt werden sollen, muss sichergestellt sein, dass alle Benutzer, die den Flow auslösen können, die nötigen Rechte auf die jeweiligen SharePoint-Objekte haben.

Personenspalten korrekt befüllen

Personenspalten in SharePoint akzeptieren keine freien Texteingaben. Power Automate erwartet für Personenspalten entweder:

• die UPN-E-Mail-Adresse (user@domain.com),
• oder ein Claims-Value-Objekt aus einer vorherigen „Get-User“-Aktion.

Ein häufiger Fehler ist die direkte Übergabe eines Displaynamens, der zwar für Menschen lesbar ist, aber nicht die erwartete Datenstruktur hat.

Datumsfehler durch Zeitzonen

Datumsfelder in SharePoint speichern Werte intern in UTC. Power Automate liefert Datumsausdrücke standardmäßig in UTC. Wenn ein Fälligkeitsdatum korrekt berechnet werden muss, sollte die Funktion convertTimeZone() verwendet werden, um UTC-Werte in die lokale Zeitzone des Nutzers oder Tenants zu überführen.

Trigger löst nicht aus

Wenn ein Flow nicht ausgelöst wird, obwohl ein Eintrag geändert wurde, sind folgende Ursachen zu prüfen:

• Der Flow ist deaktiviert.
• Die SharePoint-Verbindung ist abgelaufen oder ungültig.
• Die Trigger-Bedingungen (Trigger Conditions) schließen den konkreten Fall aus.
• Der Flow wurde im Kontext einer SharePoint-Gruppe ausgelöst, nicht eines konkreten Benutzers.
• Das verwendete Konto hat keine Leserechte auf den Trigger-Listeneintrag.

So bleibt der Aufgabenfluss auch bei Ausnahmen nachvollziehbar

Ein belastbarer Aufgaben-Workflow braucht neben der eigentlichen Ausführungslogik auch eine Fehler- und Rückfallstrategie. Die einfachste Maßnahme: Jeder kritische Schritt bekommt eine Konfiguration „Run after“ mit dem Zweig „Failed“. Dort kann entweder ein Alert an den Flow-Admin gesendet oder ein Statusfeld in der Liste auf „Fehler“ gesetzt werden.

Für Testläufe ist es sinnvoll, eine separate Testliste mit denselben Spalten wie die Produktionsliste zu betreiben. Änderungen an Flow-Logik, Trigger-Bedingungen oder Update-Feldern sollten zuerst gegen die Testliste ausgeführt werden.

Wenn ein Aufgaben-Workflow Teil einer größeren Prozesskette ist, zum Beispiel im Onboarding oder in einem Genehmigungsablauf, empfiehlt sich die Verwendung von Scope-Containern im Flow-Designer. Scopes erlauben eine klare logische Gruppierung und erleichtern das Debugging erheblich. Für das Muster, Flow-Ergebnisse anschließend in eine SharePoint-Liste zurückzuschreiben, erklärt der Artikel Ergebnisse aus Power Automate in SharePoint-Listen schreiben die notwendigen Writeback-Schritte.