Flow Builder in Shopware 6: zehn Automationen, die jeder Shop gebrauchen kann

Der Flow Builder automatisiert in Shopware 6 alles, was nach einem Ereignis passieren soll: E-Mail verschicken, Status setzen, Dokument erzeugen, Tag vergeben. Er ist in jeder Shopware-6-Version ab 6.4.6 enthalten und braucht keine Programmierung. Zeitverzögerte Aktionen und Webhooks sind den kostenpflichtigen Plänen vorbehalten oder kommen aus dem Store.

Trigger, Bedingung, Aktion

Ein Flow besteht aus drei Teilen. Sie finden ihn im Admin unter Einstellungen > Shop > Flow Builder.

• Trigger: Das Ereignis, das den Flow startet. Shopware liefert eine feste Liste, darunter „Bestellung aufgegeben“ (checkout.order.placed), Statuswechsel von Bestellung, Zahlung und Lieferung (state_enter.order_transaction.state.paid, state_enter.order_delivery.state.shipped), Kundenregistrierung, Newsletter-Anmeldung und -Bestätigung, Kontaktformular, Bewertung abgeschickt, Passwort-Wiederherstellung.
• Bedingung: Optional. Eine Regel aus dem Rule Builder, die mit „Wahr“ oder „Falsch“ verzweigt. Hinter jedem Zweig können weitere Bedingungen oder Aktionen stehen.
• Aktion: Was passieren soll. Die Liste im Standard: E-Mail verschicken, Status zuweisen (Bestellung, Zahlung, Lieferung), Dokumente erzeugen, Tag hinzufügen, Tag entfernen, Kundengruppe zuweisen, Kontostatus zuweisen, Zusatzfeld zuweisen, Affiliate- und Kampagnencode zuweisen, Download-Recht setzen, Flow anhalten. Welche Aktionen angeboten werden, hängt vom Trigger ab; bei einem Newsletter-Trigger gibt es keine Bestellung, also keine Dokumente.

Zwei Dinge sollten Sie wissen, bevor Sie loslegen. Erstens: Shopware liefert bereits Standard-Flows aus, etwa für die Bestellbestätigung und die Statusmails. Wer eine eigene Bestellbestätigung baut, muss den Standard-Flow deaktivieren, sonst bekommt der Kunde zwei Mails. Zweitens: Flows laufen in der Reihenfolge ihrer Priorität. Bei gleichem Trigger entscheidet die Prioritätszahl, wer zuerst dran ist.

Zehn Flows, die sich in fast jedem Shop lohnen

1. Bestellbestätigung je Kundengruppe. Trigger „Bestellung aufgegeben“, Bedingung „Kundengruppe = Händler“, im Wahr-Zweig die B2B-Mailvorlage, im Falsch-Zweig die Endkunden-Vorlage. So bekommen Händler Nettopreise und Hinweise zum Rechnungskauf, Endkunden die Standardmail. Den mitgelieferten Bestellbestätigungs-Flow dafür deaktivieren.
2. Tag bei Erstbestellung. Trigger „Bestellung aufgegeben“, Bedingung „Anzahl Bestellungen = 1“, Aktion „Tag hinzufügen“ am Kunden, etwa „Neukunde“. Der Tag lässt sich später für Regeln und Newsletter-Segmente nutzen, zum Beispiel für einen Gutschein auf die zweite Bestellung.
3. Interne Mail bei fehlgeschlagener Zahlung. Trigger „Zahlungsstatus: Fehlgeschlagen“ (state_enter.order_transaction.state.failed), Aktion „E-Mail verschicken“ an den Kundenservice, zusätzlich optional eine Mail an den Kunden mit dem Link zur Zahlungsart-Änderung im Kundenkonto. Ohne diesen Flow bleiben abgebrochene Zahlungen oft tagelang unbemerkt.
4. Rechnung bei Zahlungseingang erzeugen und versenden. Trigger „Zahlungsstatus: Bezahlt“, Aktion „Dokumente erzeugen“ mit Dokumenttyp Rechnung, danach „E-Mail verschicken“ mit angehängter Rechnung. Für Vorkasse-Shops die wichtigste Automation; bei PayPal und Karte läuft sie unmittelbar nach dem Checkout.
5. Download-Recht erst nach Zahlung. Für digitale Produkte: Trigger „Zahlungsstatus: Bezahlt“, Aktion „Download-Recht setzen“ auf gewährt. Shopware liefert dafür bereits einen Standard-Flow mit; prüfen Sie, ob er aktiv ist, bevor Sie einen eigenen bauen.
6. Bestellung abschließen nach Versand. Trigger „Lieferstatus: Versandt“, Bedingung „Zahlungsstatus = Bezahlt“ (Kategorie Bestellungen im Rule Builder), Aktion „Status zuweisen“ mit Bestellstatus „Abgeschlossen“. Im Falsch-Zweig nichts tun, damit unbezahlte Bestellungen offen bleiben. Spart dem Team täglich Klicks.
7. Versandbestätigung mit Sendungsnummer. Trigger „Lieferstatus: Versandt“, Aktion „E-Mail verschicken“ mit der Vorlage für den Lieferstatus. Die Mailvorlage kann die Sendungsnummern und die Tracking-URL der Versandart ausgeben; Voraussetzung ist, dass das Versand-Plugin oder die Warenwirtschaft die Nummer an die Bestellung schreibt, bevor der Status wechselt.
8. Willkommensmail nach Newsletter-Bestätigung. Trigger „Newsletter bestätigt“ (newsletter.confirm), Aktion „E-Mail verschicken“ mit einer eigenen Vorlage. Der Trigger feuert erst nach dem Double-Opt-in, nicht schon bei der Anmeldung.
9. Kunde bei Rückerstattung informieren. Trigger „Zahlungsstatus: Erstattet“ oder „Teilweise erstattet“, Aktion „E-Mail verschicken“ an den Kunden mit Hinweis, wann das Geld ankommt. Viele Zahlungs-Plugins setzen diesen Status automatisch, wenn Sie im Admin erstatten; die Kundenmail dazu fehlt im Standard.
10. Team bei neuer Bewertung benachrichtigen. Trigger „Bewertung abgeschickt“ (review_form.send), Aktion „E-Mail verschicken“ an den Shopbetreiber. Bewertungen müssen im Admin freigegeben werden, und ohne Hinweis warten sie dort wochenlang.

Ein Flow, den sich viele wünschen, fehlt in dieser Liste bewusst: die Bewertungsanfrage „14 Tage nach Lieferung“. Dafür braucht es eine Verzögerung, und die gibt es im Standard-Flow-Builder nicht. Mehr dazu im nächsten Abschnitt.

Was der Flow Builder im Standard nicht kann

Für die Community Edition heißt das: Alles, was unmittelbar auf ein Ereignis folgt, geht ohne Zusatzkosten. Alles, was warten oder mit Fremdsystemen sprechen soll, braucht eine Erweiterung oder einen Plan-Wechsel. Vor der Entscheidung für eine Delay-Erweiterung lohnt ein Blick auf deren Kompatibilität mit Ihrer Shopware-Version und darauf, ob geplante Aktionen im Admin einsehbar sind.

Bedingungen richtig einsetzen

Die Bedingungen im Flow Builder sind Regeln aus dem Rule Builder. Für Flows gibt es dort die Kategorie „Bestellungen“ mit Bestellstatus, Zahlungsstatus, Lieferstatus und „Bestellung mit Tag“. Kundenbedingungen wie Kundengruppe, Anzahl Bestellungen oder Land funktionieren ebenfalls. Bedingungen auf Positionsebene, etwa „Artikel auf Lager“ oder „Position in Kategorie“, werden bei Bestell-Triggern auf die Positionen der Bestellung angewendet. Testen Sie solche Bedingungen trotzdem einmal mit einer Testbestellung auf Staging. Ein Flow „Interne Warnung, wenn eine bestellte Position unter Mindestbestand fällt“ ist damit grundsätzlich möglich, sollte aber auf Staging getestet werden, bevor man sich darauf verlässt.

Mein Rat für Flow-Bedingungen: eigene Regeln mit dem Präfix „Flow:“ anlegen. Dann sieht jeder im Rule Builder sofort, dass diese Regel in einer Automation steckt, und nicht im Checkout.

Testen und überwachen

Flows haben keinen Testmodus. Sie testen, indem Sie das Ereignis auslösen: eine Testbestellung aufgeben, einen Status im Admin setzen, sich zum Newsletter anmelden. Für E-Mails empfehle ich auf Staging einen Mail-Catcher oder zumindest eine Umleitung aller Mails an eine interne Adresse, damit keine Testmail beim Kunden landet.

Ein ausführliches Protokoll je Flow-Durchlauf gibt es im Standard-Admin nicht. Bei ausbleibenden Mails liegt die Ursache meist nicht am Flow, sondern am Message Queue Worker, der E-Mails asynchron verschickt. Prüfen Sie dann zuerst, ob der Worker läuft:

bin/console messenger:consume async --time-limit=60

Dieser Befehl verarbeitet die Warteschlange für eine Minute. Bleiben die Mails danach aus, liegt das Problem im Flow oder in der Mailkonfiguration, andernfalls im Betrieb des Workers.

Häufige Fragen

Wenn Sie Abläufe brauchen, die über die Standard-Aktionen hinausgehen, etwa eigene Trigger oder Anbindungen an Fremdsysteme, finden Sie unter Shopware-Plugin-Entwicklung, wie ich das umsetze.