Ergebnisse aus Power Automate in SharePoint-Listen schreiben: Create, Update und Fehlerbehandlung

Wie schreibt man Ergebnisse aus Power Automate zuverlässig in eine SharePoint-Liste zurück, ohne Dubletten zu erzeugen, Datentypen zu beschädigen oder bei Fehlern keine Rückverfolgung mehr zu haben? Das Zurückschreiben von Flow-Ergebnissen in SharePoint – auch als Writeback bezeichnet – gehört zu den häufigsten Anforderungen in automatisierten Prozessen. Ob Genehmigungsentscheidungen, Berechnungsergebnisse, Statusupdates oder Formulardaten: Power Automate SharePoint Listen als persistente Datenspeicher zu nutzen, erfordert eine klare Entscheidung zwischen Neu-Anlage, Update und Upsert sowie eine durchdachte Fehlerbehandlung.

Ohne diese Überlegungen entstehen im Betrieb typische Probleme: Doppelte Einträge nach Timeouts, falsche Feldwerte durch Typ-Konflikte, stumme Fehler ohne Rückmeldung und Listen, die nach wenigen Monaten mit unvollständigen oder widersprüchlichen Einträgen vollgelaufen sind. Der Grundlagenartikel Power Automate SharePoint Prozesse ordnet ein, wann ein Writeback überhaupt Teil des Prozessmodells sein sollte.

Typische Writeback-Szenarien für SharePoint-Listen

Bevor die technischen Muster beschrieben werden, lohnt sich ein Blick auf typische Anwendungsfälle. Das Szenario bestimmt, welches Schreibmuster sinnvoll ist.

Neue Ergebnisse anlegen

Ein Flow empfängt Daten – zum Beispiel aus einem Formular, einer externen API, einem E-Mail-Parser oder einem genehmigten Antrag – und legt diese als neuen Eintrag in einer SharePoint-Liste an. Typische Beispiele:

• Umfrageergebnisse aus Microsoft Forms werden in einer Antwortliste gespeichert.
• Genehmigungsentscheidungen aus einem Approval-Flow landen mit Zeitstempel und Begründung in einer Protokollliste.
• Fehlerprotokolle aus anderen Flows werden in einer Fehlerliste erfasst.

In diesen Fällen ist „Create Item“ immer das richtige Muster. Jeder Datensatz ist einmalig, und eine Duplikatprüfung ist nur dann nötig, wenn der Flow mehrfach für dieselbe Eingabe ausgeführt werden könnte.

Bestehende Einträge aktualisieren

Ein Flow verarbeitet Daten, die bereits als Eintrag in einer Liste existieren, und soll diesen Eintrag mit einem neuen Status, einem Ergebnis oder einem Zeitstempel aktualisieren. Typische Beispiele:

• Der Bearbeitungsstatus eines Antrags wechselt von „Eingereicht“ auf „Genehmigt“.
• Ein berechneter Wert aus einer externen Quelle wird in ein Listenfeld zurückgeschrieben.
• Ein Abschlussdatum wird nach einer abgeschlossenen Aufgabe gesetzt.

In diesen Fällen ist „Update Item“ das richtige Muster. Voraussetzung: Die ID des zu aktualisierenden Eintrags muss bekannt sein.

Upsert: Anlegen oder Aktualisieren je nach Existenz

Das Upsert-Muster ist sinnvoll, wenn ein Eintrag möglicherweise bereits existiert oder noch nicht. Der Flow prüft zuerst, ob ein passender Eintrag vorhanden ist, und entscheidet dann, ob er angelegt oder aktualisiert wird.

Typische Szenarien:

• Tägliche Statusaktualisierung für Projekte: Wenn der Eintrag für heute bereits existiert, wird er aktualisiert; sonst wird er neu angelegt.
• Synchronisation aus einem externen System: Wenn das Objekt mit einer bestimmten externen ID bereits vorhanden ist, wird es aktualisiert; sonst neu angelegt.

Das Upsert-Muster ist komplexer und fehleranfälliger als einfaches Create oder Update. Es sollte nur eingesetzt werden, wenn der Anwendungsfall es wirklich erfordert.

Create Item versus Update Item versus Upsert-Muster

Create Item: neue Einträge sicher anlegen

Die Power-Automate-Aktion „Element erstellen“ (Create item) legt einen neuen Eintrag in der angegebenen SharePoint-Liste an und gibt die ID des neuen Eintrags zurück. Diese ID ist für spätere Schritte im Flow wichtig und sollte in einer Variablen gespeichert werden.

Wichtige Punkte bei Create Item:

• Pflichtfelder der Liste müssen immer befüllt werden. Fehlt ein Pflichtfeld, schlägt die Aktion fehl.
• Schreibgeschützte Felder wie „Erstellt von“ oder „Erstellt am“ können nicht direkt gesetzt werden.
• Wenn derselbe Flow mehrfach für dieselben Eingabedaten ausgeführt werden kann, sollte vor dem Anlegen eine Duplikatprüfung stattfinden.

Update Item: bestehende Einträge aktualisieren

Die Aktion „Element aktualisieren“ (Update item) benötigt zwingend die SharePoint-ID des zu aktualisierenden Eintrags sowie die Site-URL und den Listennamen. Alle anderen Felder werden optional überschrieben.

Ein wichtiges Verhalten: Update Item in Power Automate überschreibt alle angegebenen Felder. Felder, die im Formular nicht angegeben sind, bleiben unverändert. Das ist anders als bei einem HTTP-PATCH-Request, der nur die angegebenen Felder ändert. Für komplexe Updates, bei denen nur ein einziges Feld verändert werden soll, kann der SharePoint-HTTP-Request mit einem PATCH-Aufruf sinnvoller sein als die Standard-Aktion.

Upsert implementieren

Ein Upsert-Muster in Power Automate besteht aus folgenden Schritten:

1. Abfrage: „Get items“ mit einem Filter auf das eindeutige Schlüsselfeld (z.B. externe ID, E-Mail-Adresse, Projektnummer).
2. Bedingung: Ist das Ergebnis der Abfrage leer oder nicht?
3. If no: Create Item mit allen nötigen Feldern.
4. If yes: Update Item mit der ID des gefundenen Eintrags und den zu ändernden Feldern.

Die Abfrage in Schritt 1 sollte immer einen $filter-Parameter enthalten, um die Ergebnismenge auf den erwarteten Eintrag einzugrenzen. Eine ungefilterte „Get items“-Abfrage, die alle Einträge zurückgibt und dann im Flow nach dem richtigen Eintrag sucht, ist bei großen Listen langsam und fehleranfällig.

Beispiel für einen OData-Filter in „Get items“:

ExterneID eq 'AUF-2024-0815'

Der Filterwert muss als OData-Ausdruck formuliert werden. Spaltenname und Vergleichswert richten sich nach dem internen Spaltennamen der SharePoint-Liste, nicht nach dem Anzeigename.

Eindeutige Schlüssel, Abfragen und Dubletten vermeiden

Eindeutiger Schlüssel als Fundament

Das wichtigste Mittel gegen Dubletten ist ein eindeutiger Schlüssel in der Liste. SharePoint kann für geeignete Spalten eindeutige Werte erzwingen, diese Einstellung muss aber bewusst aktiviert und mit Indexierung, Berechtigungen und Fehlerbehandlung zusammengedacht werden:

• Indexiertes Textfeld mit eindeutigen Werten: Ein eigenes Feld wie „ExterneID“ oder „Antragsnummer“, das den externen Schlüssel enthält und als indexiertes Feld mit eindeutigen Werten konfiguriert ist.
• Berechnetes Feld als Hilfsspalte: Wenn mehrere Felder zusammen einen eindeutigen Wert ergeben sollen (z.B. Datum + Person), kann ein berechnetes Feld daraus einen kombinierten Schlüssel erzeugen.
• SharePoint Validation: Über Spalten-Validierungsregeln kann SharePoint eine Eingabe ablehnen, wenn ein bestimmtes Muster nicht erfüllt ist. Für fachliche Plausibilität ist das hilfreich, einen eindeutigen Schlüssel ersetzt es nicht.

Ablauf einer sicheren Duplikatprüfung

Bevor ein neuer Eintrag angelegt wird, führt der Flow eine Abfrage durch:

1. „Get items“ mit Filter auf das Schlüsselfeld.
2. Ausdruck length(body('Get_items')?['value']) prüft, ob die Ergebnismenge leer ist.
3. Wenn die Länge größer als 0, Eintrag bereits vorhanden → entweder Update oder Fehlerprotokoll.
4. Wenn die Länge gleich 0, neuen Eintrag anlegen.

Diese Prüfung schützt auch bei Timeouts und Retry-Versuchen. Wenn ein Flow nach einem Timeout erneut ausgeführt wird, wird keine Dublette erzeugt, weil der erste Lauf den Eintrag möglicherweise bereits angelegt hat.

Race Conditions bei parallelen Flows

Wenn mehrere Flows gleichzeitig für dasselbe Schlüsselfeld prüfen und anlegen, kann trotzdem eine Race Condition entstehen: Beide Flows prüfen gleichzeitig, finden nichts und legen gleichzeitig einen Eintrag an. Bei kleinen Datenmengen und asynchronen Prozessen ist dieses Risiko meistens gering. Bei zeitkritischen, hochfrequenten Flows sollte eine Parallelitätsbeschränkung oder eine Datenbankebene (z.B. Dataverse statt SharePoint) in Betracht gezogen werden.

Fehlerbehandlung, Retry, Logging und Statusfelder

Fehlerbehandlung mit „Run after“

Jede Aktion in Power Automate kann so konfiguriert werden, dass sie nur nach einem Erfolg, einem Fehler, einem Timeout oder einer Unterbrechung der vorherigen Aktion ausgeführt wird. Diese Einstellung heißt „Run after“. Sie ist entscheidend für eine belastbare Fehlerbehandlung.

Ein sinnvolles Muster für Write-Backs:

1. Versuche den Write-Back (Create oder Update Item).
2. Nach Fehler: Schreibe einen Fehlereintrag in eine separate Fehlerprotokoll-Liste mit Zeitstempel, Fehlermeldung, Flow-Lauf-ID und dem ursprünglichen Eingabewert.
3. Benachrichtige optional einen Administrator per Teams-Nachricht oder E-Mail.

Fehlerprotokoll-Einträge sollten niemals in dieselbe Liste geschrieben werden wie die erfolgreichen Einträge. Eine separate Fehlerliste macht das Monitoring deutlich einfacher.

Retry-Logik

Power Automate hat eine eingebaute Retry-Funktion für HTTP-Aktionen. Für SharePoint-Listenaktionen gibt es keine automatische Retry-Funktion im Standard. Ein Flow, der nach einem Fehler automatisch erneut versuchen soll, in eine Liste zu schreiben, muss diese Logik explizit bauen:

• Verwende eine Do-Until-Schleife mit einer Bedingung, die prüft, ob der Write-Back erfolgreich war.
• Setze eine maximale Anzahl von Iterationen, um Endlosschleifen zu verhindern.
• Führe nach jedem Fehlversuch eine kurze Delay-Aktion ein, um die Last zu verringern.

Statusfelder als Monitoring-Instrument

Ein einfacher, aber effektiver Ansatz ist ein Statusfeld in der Liste, das den aktuellen Verarbeitungsstatus des Eintrags widerspiegelt:

Statuswert	Bedeutung
Ausstehend	Eintrag wurde angelegt, noch nicht vom Flow verarbeitet
In Bearbeitung	Flow läuft gerade
Abgeschlossen	Flow hat den Eintrag erfolgreich verarbeitet
Fehler	Flow-Verarbeitung ist fehlgeschlagen

Wenn der Flow startet, setzt er das Statusfeld auf „In Bearbeitung“. Nach dem erfolgreichen Abschluss setzt er es auf „Abgeschlossen“. Im Fehlerfall setzt er es auf „Fehler“. So ist jederzeit erkennbar, welche Einträge korrekt verarbeitet wurden und welche erneut geprüft werden müssen.

Typische Probleme mit Datentypen, Personenfeldern und Mehrfachwerten

Datentyp-Konflikte

SharePoint-Felder erwarten Werte in einem bestimmten Format. Power Automate liefert Ausgaben, die manchmal nicht direkt kompatibel sind:

• Datumsfelder: SharePoint erwartet Daten im ISO-8601-Format (z.B. 2024-06-15T00:00:00Z). Wenn ein Flow ein Datum aus einem Formular als Text empfängt, muss es konvertiert werden.
• Zahlfelder: Dezimalzahlen mit Komma statt Punkt als Trennzeichen werden nicht akzeptiert.
• Boolsches Feld (Ja/Nein): Power Automate verwendet true oder false (Boolean), nicht „Ja“/„Nein“ als Text.

Personenfelder

Wie bereits in der Beschreibung der Aufgaben-Workflows erwähnt: Personenspalten in SharePoint erfordern eine gültige Claims-Repräsentation. In Power Automate wird für Personenspalten ein JSON-Objekt mit der E-Mail-Adresse oder dem Wert Claims übergeben:

{"Email": "user@domain.com"}

Alternativ kann die Aktion „Office 365-Benutzer abrufen“ verwendet werden, die ein kompatibles Benutzerobjekt zurückgibt.

Mehrwertige Spalten

SharePoint-Listen unterstützen Spalten, die mehrere Werte aufnehmen können (z.B. mehrere Tags, mehrere Kategorien). Das Schreiben in mehrwertige Spalten erfolgt über ein Array:

{"results": ["Wert1", "Wert2", "Wert3"]}

Ein einfacher Textwert reicht nicht aus. Wenn der Flow einen mehrwertigen Text aus einer Eingabe übergibt, muss dieser zunächst in ein Array aufgesplittet werden (z.B. mit der Funktion split()).

Nachschlagespalten (Lookup fields)

Nachschlagespalten verweisen auf Einträge in einer anderen Liste. Beim Schreiben muss die numerische ID des referenzierten Eintrags übergeben werden, nicht der angezeigte Text. Der Wert muss als Integer oder als Lookup-Value-Objekt übergeben werden:

{"Id": 42}

So bleibt das Writeback auch bei Fehlern und Doppeleinträgen robust

Ein belastbarer Writeback-Prozess hängt von drei Dingen ab: einem eindeutigen Schlüssel, einer sauberen Fehlerbehandlung und einer testbaren Laufzeitkontrolle. Alle drei lassen sich ohne großen Aufwand implementieren, wenn sie von Anfang an eingeplant werden.

Für die Last und Laufzeit gilt: SharePoint-Listen sind für moderate Datenmengen und Schreibfrequenzen gut geeignet. Wenn ein Flow sehr hohe Schreiblasten erzeugt, etwa Hunderte oder Tausende Einträge pro Stunde, sollte Dataverse als Alternative geprüft werden. Dataverse bietet echte Constraints, bessere Indexierung und eine API, die für höhere Last ausgelegt ist. Für Standard-Geschäftsprozesse in SharePoint-basierten Umgebungen ist eine gut aufgebaute Liste mit Statusfeldern und Fehlerprotokoll in den meisten Fällen jedoch ausreichend.

Wenn das Writeback in eine Liste Teil eines Aufgaben-Workflows ist, erklären die Trigger- und Statusmodelle im Artikel SharePoint-Aufgaben mit Power Automate verbinden die vorgelagerte Seite des Prozesses. Für Prozesslösungen mit Apps, Automatisierung und Auswertung zeigt Power Platform mit SharePoint, wie Writeback, Oberfläche und Reporting zusammenpassen.