Von Power Automate zu n8n mit drei Workflows

Ich habe die Anfragekette im Eventforum durch drei n8n-Workflows ersetzt. n8n läuft selbst betrieben in Docker und übernimmt den Eingang, den Abgleich mit SharePoint und den Tagesblick. Power Automate und Planner sind aus dem Ablauf entfernt.

Die alte Kette war eng gekoppelt

Bis September 2026 liefen zehn Power-Automate-Flows mit einer SharePoint-Liste, Eventordnern und Aufgaben in Planner. Fast alles hing an einer einzigen Verbindung. Die Auslöser lasen Auswahlspalten direkt aus, wodurch ich die Liste und die Flows nur gemeinsam ändern konnte.

Ein Flow meldete bei jedem Lauf «Erfolgreich» und erledigte trotzdem keine Arbeit. Er wartete auf eine Spalte, die es nicht gab. Aufgefallen ist mir das über die Laufzeit. Dieser Flow brauchte 0,4 bis 0,9 Sekunden, während die übrigen 5 bis 8 Sekunden liefen.

Auch der Mail-Parser war eng an seine Quelle gebunden. Er suchte nach wörtlichen Textmarken in der Formularmail und brach still ab, sobald sich die Vorlage änderte. Der Umbau gehört zum Betrieb auf der Projektseite Eventforum.

Drei Workflows übernahmen die Aufgaben

Mit dem Relaunch der Website am 20. September 2026 riss die bisherige Kette. Am 21. September 2026 um 20:45 Uhr wurde n8n zum einzigen Eingang. Eine halbe Stunde später entschied ich, den Ablauf vollständig ohne Power Automate und Planner weiterzuführen. Seit dem 22. September 2026 um 18:00 Uhr sind alle zehn Flows ausgeschaltet. Einer bleibt als Rückfall erhalten.

Die Drehscheibe nimmt neue Anfragen entgegen. Ein Webhook ist dabei ein HTTP-Aufruf, den n8n verarbeitet. Die Funktionsweise zeigt auch die Dokumentation zum Webhook-Knoten in n8n. Pro Anfrage verschickt der Workflow genau eine Mail ans Team. Diese Mail enthält keine internen Links und kann dadurch weitergeleitet werden.

Der Wächter liest die SharePoint-Liste alle 5 Minuten über Microsoft Graph. Dafür verwendet er Delta-Abfragen in Microsoft Graph, die Änderungen seit dem letzten Abruf liefern. Der Tagesblick läuft um 07:00 Uhr. Die Aufgaben stehen nun in sieben neuen Spalten der Liste und in einer eigenen Ansicht. Ich habe 44 laufende Einträge übernommen.

Verzögerungen und Fehler wurden sichtbar

Die erste Anfrage nach der Umstellung stand am 22. September 2026 nach 4 Sekunden in Liste, Ordner und Postfach. Am 30. September 2026 vergingen 10 Sekunden vom Klick bis zur Mail. Am 1. Oktober 2026 startete der Lauf erst 22 beziehungsweise 24 Sekunden nach dem Absenden.

Die Ursache lag beim Formular-Plugin FluentForms. Es verschickt seine Webhooks über WP-Cron. Dieser Mechanismus läuft nur, wenn jemand eine Seite aufruft. Seither stösst der Server WP-Cron jede Minute an.

Am 22. September 2026 fiel zudem auf, dass der Fehler-Workflow seit seinem Bau inaktiv war. Am 23. und 24. September 2026 kamen zwei Anfragen ohne Mail an. Die Fehlermeldungen gingen damals nur an ein privates Postfach. Danach ergänzte ich eine Rückfall-Mail, Meldungen ans Team, drei Wiederholungen und einen Wächter per WhatsApp.

Der eigene Betrieb brachte weitere Fallen

n8n läuft in Docker auf einem Linux-Server mit Ubuntu 24.04. Caddy steht als Webserver davor und verwendet Zertifikate von Let's Encrypt. Die Oberfläche ist nur von freigegebenen Adressen aus erreichbar. Die n8n-Dokumentation beschreibt den allgemeinen Weg unter n8n mit Docker installieren.

Im HTTP-Knoten setze ich den Body nie als Ausdruck. Microsoft Graph antwortete in diesem Fall mit Fehler 500. Ich habe sieben Varianten gemessen. Hyperlink-Spalten lassen sich über Microsoft Graph nicht beschreiben. Datumsspalten kommen als UTC-Mitternacht der Zürcher Zeit an.

Auch die Mails brauchten eine Anpassung. Outlook verwirft beim Antworten das Stylesheet. Deshalb steht das CSS inline, und das Logo hängt als PNG direkt in der Mail.

Am 1. Oktober 2026 aktualisierte ich n8n von Version 2.39.10 auf 2.41.5. Ich verwendete ein festgelegtes Image, erstellte eine kalte Vollsicherung und machte eine Probe ohne Netz. Die Workflows blieben unverändert.

Was ich daraus mitnehme

Ich beurteile einen erfolgreichen Lauf auch über seine Dauer und sein Ergebnis. Bei Webhooks gehört für mich die auslösende Zeitsteuerung zur ganzen Kette. Fehlermeldungen müssen denselben betrieblichen Weg erreichen wie die Anfragen. Der eigene Betrieb macht diese Abhängigkeiten für mich sichtbar.

---

Modell dieser Notiz: gpt-5.6-sol.