Zwei Betriebsmodelle
WordPress-Workflows: externer Dienst oder eigenes AWS?
Ein WordPress-Formular kann Daten an Zapier, Make, n8n oder einen anderen Automatisierungsdienst senden. Es kann aber auch direkt mit einem selbst betriebenen Anwendungs-Backend sprechen. Entscheidend ist weniger das Formular als die Frage, wo Daten, Workflow-Zustand und Verarbeitung liegen.
Kurz gesagt Ein externer Automatisierungsdienst passt gut, wenn fertige Anbindungen und ein verwalteter Betrieb die einfachste Lösung sind. Ein eigenes Backend passt besser, wenn das Formular Teil der Anwendung ist und Daten, Zustände und Verarbeitung möglichst in der eigenen Infrastruktur bleiben sollen.
Nach dem Absenden
Der zusätzliche Dienst in der Mitte ist eine Architekturentscheidung
Mit einem Webhook lässt sich fast jedes Formular automatisieren. Die eigentliche Frage ist, ob zwischen Besucher und Zielsystem zwingend noch ein externer Automatisierungsdienst stehen soll.
Datenweg
Formulardaten können durch einen weiteren Dienst laufen
Bei einem gehosteten Automatisierungsdienst gelangen Formulardaten in der Regel zuerst in dessen Laufzeit, bevor sie die Zielsysteme erreichen. Das kann akzeptabel sein, ist aber eine zusätzliche Datengrenze.
Workflow-Zustand
Der Prozess verteilt sich auf mehrere Systeme
Das Formular kann in WordPress liegen, die Automatisierung in einem anderen Dienst und der fachliche Zustand in einem dritten System. Fehlersuche umfasst dann mehrere Protokolle, Rechte und Aufbewahrungsregeln.
Nutzungsmodell
Mit dem Prozess wächst eine weitere Nutzungsebene
Gehostete Automatisierungsdienste haben eigene Tarife und Nutzungsgrenzen. Die Abrechnung unterscheidet sich je nach Anbieter, bleibt aber eine zusätzliche Ebene neben der eigentlichen Anwendungsinfrastruktur.
Die Entscheidung Ist das Formular nur der Einstieg in eine Anwendung, die bereits in eigener Infrastruktur läuft, kann der zusätzliche Automatisierungsdienst sinnvoll, optional oder überflüssig sein.
Die Betriebsgrenze vergleichen
Drei Fragen trennen die beiden Ansätze
Flow kann weiterhin externe Automatisierungsdienste aufrufen. Der Unterschied ist, ob sie zum normalen Datenweg gehören müssen.
| Frage | Externer Automatisierungsdienst | Flow im eigenen AWS |
|---|---|---|
| Wo laufen Formulardaten und Workflow-Zustände durch? | Durch die Laufzeit des Anbieters, bevor oder während Aktionen an verbundene Systeme weitergegeben werden. | Flow kann direkt an einen eingerichteten Endpunkt senden oder im AWS-Backend Einsendungen, Entwürfe, Prüfstatus und Workflow-Ereignisse verwalten. |
| Können Auswahlwerte schon vor dem Absenden aus aktuellen Anwendungsdaten kommen? | Häufig ja, abhängig davon, wie Formular- und Automatisierungsprodukt entfernte Datenquellen anbinden. | Ja. Auswahl-, Options-, Checkbox-Gruppen- und Tag-Felder können Werte per API oder Fernsuche laden, einschließlich Zuordnung der Antwortfelder und Zwischenspeicherung. |
| Was bestimmt das Ausführungsmodell? | Der Anbieter führt die Automatisierung aus und verwendet eigene Tarife, Grenzen und Nutzungsmodelle; selbst gehostete Produkte sind ein eigener Fall. | Die Workflow-Dienste laufen im gewählten AWS-Konto. WP Suite erhebt keinen eigenen Zähler pro Workflow-Schritt; AWS-Kosten entstehen durch die tatsächlich genutzten Dienste und Rechenzeit. |
Das Betriebsmodell ist wichtiger als die reine Zahl der Anbindungen
Externer Automatisierungsdienst
Passend, wenn fertige Anbindungen im Vordergrund stehen
- Das Team nutzt den Dienst und seine Anbindungen bereits.
- Es ist akzeptabel, dass die betreffenden Daten auch über diesen Anbieter laufen.
- Ein verwalteter Automatisierungsbetrieb ist wichtiger als ein eigenes Workflow-Backend.
Flow im eigenen AWS
Passend, wenn das Formular innerhalb der Anwendungsgrenze bleiben soll
- Einsendungen, gespeicherte Entwürfe, Prüfstatus und Workflow-Daten sollen in kontrollierter Infrastruktur bleiben.
- Die öffentliche WordPress-Seite kann statisch sein, während Formulare und Workflows per Browser-zu-API-Verbindung weiterlaufen.
- Formularfelder sollen aktuelle API-Daten laden oder Prozesse auslösen, ohne dass dafür zwingend ein weiterer Formular- oder Automatisierungsdienst dazwischenliegt.
Häufige Fragen
Flow mit oder ohne externen Automatisierungsdienst
Kann Flow Daten an n8n, Make, Zapier oder andere Dienste senden?
Ja. Über Webhooks und nachgelagerte Aktionen können externe Automatisierungen eingebunden werden. Für das Flow-Backend sind sie jedoch nicht zwingend erforderlich.
Kann Flow Auswahlwerte vor dem Absenden aus einer API laden?
Ja. Mehrere Auswahlfelder unterstützen API-Quellen und Fernsuche mit Antwortzuordnung, Parametern, Headern und Zwischenspeicherung.
Ersetzt Flow jede Automatisierungsplattform?
Nein. Ein externer oder selbst gehosteter Automatisierungsdienst kann der kürzere Weg sein, wenn vor allem dessen große Anbindungsbibliothek oder bestehende Automatisierungen gebraucht werden.
Braucht Flow einen öffentlich laufenden WordPress-Server?
Nein. Der Browser kann die eingerichtete API direkt aufrufen. Formulare, gespeicherte Entwürfe und Workflows funktionieren daher auch mit statisch veröffentlichtem WordPress.
Den Ablauf im Detail ansehen
Was nach dem Absenden eines WordPress-Formulars passiert
Die vorhandenen Lösungs- und Architekturseiten zeigen, wie Prüfung, Freigabe, Ereignisse und Folgeaktionen außerhalb des WordPress-Aufrufs laufen können.