Flow Builder: Auslöser, Aktionen und Grenzen
Der Flow Builder bringt 17 Aktionen im Kern mit — und keine davon spricht mit einem fremden System. Das ist die Grenze, an der die meisten Automatisierungsvorhaben ankommen.
Der Flow Builder ist die naheliegende Antwort auf „können wir das automatisieren". Er ist im Backend, braucht keine Entwicklung und deckt eine überraschende Menge ab. Er hat aber eine klare Grenze, und die steht nirgends so deutlich, wie sie sich im Projekt bemerkbar macht.
Die 17 Aktionen im Kern
Gezählt in einer laufenden 6.7.13.1-Installation — und, zum Vergleich, in 6.6.10.6. Beide Male dieselbe Zahl und dieselbe Liste:
| Bereich | Aktionen |
|---|---|
| Kunde | Kundengruppe ändern, Kundenstatus ändern, Tag hinzufügen, Tag entfernen, Zusatzfeld setzen, Zusatzfeld der Kundengruppe setzen, Affiliate- und Kampagnencode setzen |
| Bestellung | Bestellstatus setzen, Tag hinzufügen, Tag entfernen, Zusatzfeld setzen, Affiliate- und Kampagnencode setzen |
| Kommunikation | E-Mail senden |
| Dokumente | Dokument erzeugen, Downloadzugriff gewähren |
| Ablaufsteuerung | weiteren Ablauf starten, Ablauf anhalten |
Was in dieser Liste fehlt: jede Aktion, die mit einem System ausserhalb von Shopware spricht. Kein HTTP-Aufruf, kein Warteschlangeneintrag, kein Dateiexport.
Das ist keine Nachlässigkeit, sondern eine Architekturentscheidung. Der Weg nach draussen sind Webhooks — sie sind entkoppelt, haben eine Wiederholung und ein Protokoll. Wie das funktioniert und wo es aufhört, steht in Webhooks in Shopware 6.
Was das für die Planung bedeutet
Die meisten Automatisierungsvorhaben lassen sich vor der ersten Zeile Code sortieren:
| Vorhaben | passt in den Flow Builder? |
|---|---|
| Bei Bestellstatus X eine E-Mail an den Kunden | ja |
| Kunden nach erster Bestellung in eine Gruppe verschieben | ja |
| Rechnung automatisch erzeugen, wenn bezahlt | ja |
| Bestellung an die Warenwirtschaft übergeben | nein — Webhook oder Erweiterung |
| Lagerbestand aus einem fremden System holen | nein — geplante Aufgabe oder Import |
| Nachricht in einen Chatkanal schreiben | nein — Webhook |
| Alle Produkte einer Kategorie täglich prüfen | nein — der Flow Builder ist ereignisbezogen |
Die letzte Zeile wird oft übersehen: Ein Ablauf startet, wenn ein Ereignis eintritt. Es gibt keine Schleife über Datensätze und keinen Zeitplan. Wer regelmässig alle Produkte anfassen will, braucht eine geplante Aufgabe.
Und die dritte Zeile hat einen Haken, der nicht im Flow Builder liegt: Der Ablauf löst die Erzeugung aus, über den Inhalt des Dokuments entscheidet er nicht. Was Shopware dabei tatsächlich schreibt — Profil, Rechnungsnummer, Zahlungsmittel — steht in E-Rechnung im Shopware-Kern.
Auslöser: mehr als Aktionen, und erweiterbar
Die Auslöserliste im Backend ist deutlich länger als die Aktionsliste. Sie kommt aus den Geschäftsereignissen des Kerns — und sie wächst mit jeder Erweiterung, die eigene Ereignisse anmeldet.
Das ist der Hebel, den viele nicht kennen. Unser Wunschlisten-Plugin steuert zum Beispiel elf eigene Auslöser bei — vom Anlegen einer Liste bis zum Teilen. Damit lassen sich Abläufe bauen, für die es im Kern keinen Anlass gibt.
Ein Hinweis aus der Praxis: Die Anzahl der Ereignisklassen einer Erweiterung sagt nichts über die Anzahl der Auslöser. Massgeblich ist, was der Ereignissammler tatsächlich anmeldet — nicht, wie viele Dateien nach Ereignis aussehen. Wir haben uns daran selbst einmal verzählt.
Was bei einem Fehler passiert
Nichts Aufwendiges: Der Ablauf endet an der fehlgeschlagenen Aktion. Es gibt keine Wiederholung wie bei Webhooks und keinen Fehlerpfad, der eine Meldung absetzt.
Für viele Abläufe ist das in Ordnung — eine nicht gesendete Statusmail ist ärgerlich, aber kein Datenverlust. Für Vorgänge, die nicht ausfallen dürfen, ist es ein Argument gegen den Flow Builder und für eine Lösung mit Fehlerbehandlung. Wie so etwas ausserhalb von Shopware aussieht, beschreibt Fehlerbehandlung in Make.
Zwischen 6.6 und 6.7 unverändert
Beide Runtimes zeigen dieselben 17 Aktionen. Für die Planung heisst das: Der Wechsel auf 6.7 bringt in diesem Bereich nichts Neues — weder mehr Möglichkeiten noch Anpassungsbedarf. Was sich sonst zwischen den beiden Linien messbar unterscheidet, steht in Auf Shopware 6.7 wechseln oder bei 6.6 bleiben.
Eine Reihenfolge, die Arbeit spart
- Auslöser suchen. Gibt es das Ereignis? Wenn nein, endet es hier — oder eine Erweiterung muss es beisteuern.
- Aktion suchen. Steht sie in der Liste oben? Wenn nein: Webhook.
- Fehlerfall klären. Was passiert, wenn die Aktion scheitert? Ist das tragbar?
- Erst dann bauen.
Die drei Fragen dauern zehn Minuten und ersparen die häufigste Enttäuschung: einen halb gebauten Ablauf, der an Schritt zwei scheitert.
Wenn dabei herauskommt, dass eine eigene Aktion oder ein eigener Auslöser nötig ist — das ist gewöhnliche Erweiterungsarbeit und gehört zu App- und Plugin-Entwicklung.
Häufige Fragen
- Kann der Flow Builder eine HTTP-Anfrage senden?
- Im Kern nicht. Es gibt keine Aktion dafür. Der vorgesehene Weg nach draussen sind Webhooks; Erweiterungen können eigene Aktionen ergänzen.
- Wie viele Auslöser gibt es?
- Die Liste im Backend kommt aus den Geschäftsereignissen und ist deutlich länger als die Aktionsliste. Sie wächst mit installierten Erweiterungen, weil diese eigene Ereignisse anmelden können.
- Was passiert, wenn eine Aktion fehlschlägt?
- Der Ablauf endet an dieser Stelle. Es gibt keine Wiederholung wie bei Webhooks. Für Vorgänge, die nicht verloren gehen dürfen, ist das ein Argument gegen den Flow Builder.
- Kann ich Abläufe verzweigen?
- Ja, über Bedingungen auf Basis der Regeln. Was nicht geht, sind Schleifen über Datensätze — der Flow Builder arbeitet ereignisbezogen, nicht als Stapelverarbeitung.