Automatisierung mit Shopify Flow

Automatisierung mit Shopify Flow

0:00 Eine Automatisierung ist wie eine Mitarbeiterin, die nie krank wird und nie nachfragt. Beides ist ein Vorteil — und beides ist das Problem. Sie arbeitet auch dann weiter, wenn sich die Lage geändert hat, und sie stellt keine Rückfrage, wenn etwas seltsam aussieht. In diesem Modul bauen wir deshalb nicht nur Workflows, sondern vor allem die Regeln um sie herum: Was passiert im Fehlerfall, wer ist zuständig, und welche Aktionen brauchen eine menschliche Freigabe?

Automatisierung mit Shopify Flow

0:27 Vier Kapitel. Zuerst der Aufbau eines Workflows — es sind nur drei Arten von Bausteinen, das ist schnell erklärt. Dann drei Muster, die den Großteil der Praxisfälle abdecken. Danach Benachrichtigungen und externe Systeme, wo der Tarif überraschend deutlich hineinregiert. Und zum Schluss der Betrieb: Fehlerfälle, Dokumentation, Freigaben.

0:48 In der Übung bauen Sie drei Workflows für Steglicht — mit Fehlerregel und Eskalationsweg, nicht nur mit Auslöser und Aktion.

Aufbau eines Flow-Workflows

0:56 Beginnen wir mit dem Baukasten. Er ist kleiner, als man denkt — und genau das macht ihn brauchbar. Shopify Flow ist eine Automatisierungsplattform für Aufgaben und Abläufe im Shop und über Apps hinweg. Ein Workflow besteht aus drei Arten von Bausteinen: einem Auslöser, beliebigen Bedingungen und einer oder mehreren Aktionen. Mehr gibt es nicht.

1:17 Das ist bewusst so gehalten, und es ist der Grund, warum auch Leute ohne Entwicklungshintergrund damit arbeiten können. Die Komplexität entsteht nicht in den Bausteinen, sondern in den Fragen davor: Wann genau soll das auslösen, und was soll dann passieren? Drei Glieder, und die Reihenfolge ist zwingend. Der Auslöser ist ein Ereignis im Shop — eine Bestellung wird erstellt, ein Bestand ändert sich.

1:42 Die Bedingung entscheidet, ob es weitergeht: nur bei diesem Produkt, nur über diesem Betrag. Und die Aktion tut etwas: ein Tag setzen, eine Nachricht senden, die Erfüllung anhalten. Der praktische Rat dazu: Formulieren Sie einen Workflow erst als Satz — wenn dieses passiert und jenes zutrifft, dann tue das. Wer den Satz nicht sauber hinbekommt, sollte noch nicht klicken.

2:05 Hier wird es technisch, aber sehr praktisch. Flow greift auf die GraphQL Admin API zu, zum Stichtag in der Version 2026-01 — das ist übrigens nicht dieselbe Version wie die aktuelle Admin API, die auf 2026-07 steht. Zwei Stände im selben Shop also. Nahezu alle Felder der API stehen in Variablen zur Verfügung, und die Variablennamen folgen der API-Schreibweise.

2:30 Manche Felder brauchen ein Argument — ob ein Produkt in einer Kollektion ist, lässt sich nur beantworten, wenn man sagt, in welcher. Der erste Punkt ist der häufigste Anfängerfehler und er hat eine klare Fehlermeldung: Der Auslöser liefert Kundendaten, die Aktion erwartet Bestelldaten — Fehler wegen fehlender Daten. Die Datenarten müssen zusammenpassen. Der zweite ist subtiler: Ein Feld wird ohne das nötige Argument verwendet und bleibt einfach leer.

2:58 Der dritte ist ein Betriebsrisiko: Eine API-Version entfernt ein Feld, und der Workflow muss von Hand nachgezogen werden. Und der vierte ist der, der die meiste Nacharbeit spart, wenn man ihn vermeidet: bauen, bevor der Prozess auf Papier steht.

Typische Workflows im Shopalltag

3:13 Weiter mit der Praxis. Erfreulicherweise decken drei Muster den Großteil dessen ab, was Shops tatsächlich automatisieren. Die wiederkehrenden Automatisierungen im Handel folgen wenigen Mustern. Etwas wird knapp und jemand muss es wissen. Etwas ist auffällig und muss markiert werden. Jemand verhält sich besonders und soll anders behandelt werden. Drei Sätze, und darunter fällt erstaunlich viel.

3:37 Das ist eine gute Nachricht für den Einstieg: Sie müssen nicht kreativ werden, sondern nur Ihre eigenen Fälle diesen drei Mustern zuordnen. Wenn ein Fall in keines passt, lohnt die Nachfrage, ob er wirklich automatisiert gehört. Drei Zeilen, die Sie direkt nachbauen können. Bestandswarnung: Der Bestand unterschreitet eine Grenze, eine Nachricht geht an den Einkauf.

3:59 Risikomarkierung: Eine Bestellung wird erstellt, ein Tag wird gesetzt und die Erfüllung angehalten — Vorsicht, hier greift die Automatisierung aktiv in den Betrieb ein. Kundensegmentierung: Eine Bestellung wird bezahlt, und bei Überschreiten eines Schwellenwerts wird der Kunde getaggt. Die Fußzeile nennt die Bedingung, die alle drei teilen: Jeder dieser Workflows braucht eine Regel, was bei einem Fehlalarm geschieht.

4:24 Über Bestell-Workflows spricht jeder, über Produkt-Workflows kaum jemand — dabei sparen sie oft mehr Zeit. Neue Produkte lassen sich automatisch in Kollektionen oder Kanäle aufnehmen. Fehlende Pflichtfelder lassen sich beim Anlegen markieren, statt sie später zu suchen; das ist praktisch eine Qualitätssicherung für den Katalog aus Modul drei.

4:44 Auslaufende Ware lässt sich automatisch aus Feeds und Kanälen nehmen — eine direkte Antwort auf den veralteten Feed aus Modul dreizehn. Und redaktionelle Aufgaben lassen sich anstoßen, aber nicht entscheiden. Diese Grenze bleibt. Der erste Punkt ist der, der Bestandswarnungen unbrauchbar macht: Der Schwellenwert gilt für alle Produkte gleich — dabei hat ein Schnelldreher einen anderen Bedarf als ein Langsamdreher.

5:08 Der zweite ist ein Zuständigkeitsloch mit Folgen: Risikobestellungen werden markiert, aber niemand sieht die Markierung an. Der dritte wächst über die Zeit: Ein Tag wird gesetzt und nie wieder entfernt — nach zwei Jahren trägt die halbe Kundschaft ein Etikett von damals. Und der vierte ist ein Zeitproblem: Der Workflow löst aus, obwohl der Vorgang noch nicht abgeschlossen ist.

Benachrichtigungen und externe Systeme

5:30 Jetzt der Blick nach draußen. Und eine Tarifgrenze, die man kennen muss, bevor man plant. Flow ist eine kostenlose App und steht auf Basic, Grow, Advanced und Plus zur Verfügung. Der Umfang unterscheidet sich allerdings. Die Aktion Send HTTP Request — also der Ruf an ein externes System — gibt es erst ab Grow. Aufgaben aus eigenen Partner-Apps gibt es nur mit Shopify Plus.

5:54 Und die Nutzungsgrenzen folgen den API-Grenzen des jeweiligen Tarifs. Für die Projektplanung heißt das: Automatisierung ist überall möglich, aber nicht überall über die Grenzen des Shopify-Ökosystems hinaus. Drei Zeilen, die eine Planung entscheiden können. Flow selbst mit Auslösern, Bedingungen und Aktionen: alle Tarife.

6:16 Die Aktion Send HTTP Request: Grow, Advanced, Plus — also nicht Basic. Aufgaben aus eigenen Partner-Apps: nur Plus. Der Satz in der Fußzeile ist die praktische Übersetzung: Für Basic endet die Automatisierung am Rand des Shopify-Ökosystems. Innerhalb davon können Sie viel tun; ein eigenes System anzubinden gehört nicht dazu.

6:37 Das ist kein Mangel, sondern eine Tarifgrenze — man muss sie nur kennen, bevor man das Konzept schreibt. Vier Fragen, die vor dem ersten HTTP-Aufruf stehen sollten. Wer ist beim Empfänger zuständig, wenn der Aufruf fehlschlägt? Verträgt der Empfänger denselben Aufruf zweimal — denn Wiederholungen passieren. Welche Daten verlassen den Shop, und auf welcher Grundlage; das ist die Brücke zu Modul zweiundzwanzig. Und wird eine Antwort ausgewertet oder nur abgeschickt?

7:07 Der letzte Punkt klingt banal und ist der häufigste: Ein Aufruf, dessen Antwort niemand ansieht, ist eine Hoffnung mit technischem Unterbau. Der erste Punkt ist die Tarifgrenze, die zu spät auffällt: Der HTTP-Aufruf wird eingeplant, der Shop läuft aber auf Basic. Der zweite ist ein Datenschutzthema mit Ansage: Personenbezogene Daten gehen an ein externes System, ohne dass eine Vereinbarung besteht.

7:32 Der dritte ist ein Zuverlässigkeitsproblem: Der Empfänger ist kurz nicht erreichbar, und der Vorgang geht verloren — deshalb braucht es einen Abgleich, wie in Modul neunzehn. Und der vierte wächst leise: Drittanbieter-Apps bringen eigene Aktionen mit, die niemand dokumentiert.

Betrieb der Automatisierung

7:49 Zum Abschluss der Teil, der über Erfolg entscheidet: Automatisierungen brauchen einen Besitzer, nicht nur einen Erfinder. Ein laufender Workflow ist Betriebsmittel. Er kann fehlschlagen, doppelt auslösen oder nach einer Änderung an Katalog oder API stillschweigend danebengreifen — und das ist der unangenehmste Fall, weil nichts kaputtgeht, sondern nur etwas Falsches passiert.

8:11 Deshalb gehört zu jedem Workflow dreierlei: ein Verantwortlicher, eine Fehlerregel und ein Prüftermin. Drei Angaben, die man in einer Zeile notiert und die den Unterschied machen zwischen einer Automatisierung, die trägt, und einer, die irgendwann jemand vorsichtshalber abschaltet. Fünf Schritte. Schreiben Sie Zweck, Auslöser und erwartete Wirkung auf — in einem Satz, wie vorhin. Benennen Sie den Fehlerfall: Was passiert, wenn die Aktion scheitert?

8:38 Prüfen Sie, welche Aktionen eine menschliche Freigabe brauchen. Starten Sie mit einem eng gefassten Auslöser und beobachten Sie; eng gefasst heißt: lieber zu wenige Fälle als zu viele. Und halten Sie Verantwortlichen und Prüftermin fest, bevor Sie ausweiten. Risikoreiche Aktionen wie Stornierungen und Erstattungen gehören ohnehin hinter eine Freigabe.

9:00 Vier Gründe, und der erste erklärt alle anderen: Ein Workflow ist unsichtbar, solange er funktioniert. Niemand sieht ihn im Alltag; man sieht nur seine Wirkung. Nach einem Personalwechsel weiß deshalb niemand mehr, warum ein bestimmtes Tag gesetzt wird. Änderungen an einem Workflow lassen sich schwer nachvollziehen — es gibt keine Versionshistorie, wie in Modul zwei.

9:22 Und der vierte Punkt ist die praktische Folge: Wer den Zweck nicht kennt, schaltet im Zweifel ab statt zu reparieren. Damit geht Automatisierung verloren, die einmal Arbeit gespart hat. Der erste Punkt ist schwer zu finden und ärgerlich: Zwei Workflows greifen auf denselben Vorgang zu und überschreiben sich gegenseitig. Der zweite ist der gefährlichste Fehlerfall überhaupt: Ein Fehler wird stillschweigend verschluckt, und der Vorgang bleibt liegen — niemand merkt es, bis die Kundschaft nachfragt.

9:51 Der dritte passiert in jedem Shop mindestens einmal: Workflows werden zum Testen aktiviert und bleiben aktiv. Und der vierte ist die stille Alterung: Nach einer Sortimentsumstellung greift die Bedingung ins Leere, und der Workflow läuft folgenlos weiter.

Übung

10:06 Jetzt bauen Sie drei Workflows für Steglicht — und zwar vollständig, also samt der Regeln für den Fall, dass sie nicht tun, was sie sollen. Bei Steglicht sollen drei Abläufe automatisch laufen: eine Warnung bei kritischem Bestand, die Kennzeichnung risikoreicher Bestellungen und die Segmentierung besonders wertvoller Kundschaft.

10:25 Der Shop läuft auf einem Standardtarif — diese Angabe ist kein Beiwerk, sondern Teil der Aufgabe. Denn sie entscheidet mit, welche Aktionen überhaupt zur Verfügung stehen. Drei Workflows, drei Muster: Sie erkennen die Tabelle aus Kapitel zwei wieder, jetzt allerdings mit echten Schwellenwerten und echten Verantwortlichen.

10:43 Das Lernziel: Automatisierungen so entwerfen, dass ihr Fehlerfall und ihre Zuständigkeit vor der Aktivierung feststehen. Vor der Aktivierung — danach findet sich nie wieder Zeit dafür. Erfolgreich sind Sie, wenn drei Workflows als Auslöser, Bedingung und Aktion vorliegen, jeder mit Fehlerregel, Eskalationsweg, Verantwortlichem und Prüftermin, und wenn die Tarifabhängigkeit geprüft ist.

11:06 Und wer früh fertig ist, beschreibt, woran ein Fehlalarm erkannt wird — denn den zu erkennen ist schwerer, als ihn zu vermeiden. Bestimmen Sie je Ablauf den Auslöser und prüfen Sie, ob die nötigen Daten dort überhaupt zur Verfügung stehen. Fassen Sie die Bedingungen so eng, dass Fehlalarme selten bleiben — lieber ein Fall zu wenig am Anfang. Legen Sie die Aktionen fest und prüfen Sie sie gegen den Tarif.

11:31 Halten Sie je Workflow Fehlerregel und Eskalationsweg fest. Und tragen Sie Verantwortliche und Prüftermine ein. Diese letzte Spalte ist der Unterschied zwischen einem Workflow, der gepflegt wird, und einem, der irgendwann stört. Der erste Punkt ist der, der Bestandswarnungen in Rauschen verwandelt: Der Schwellenwert gilt pauschal, und die Schnelldreher fehlen ständig.

11:53 Der zweite greift aktiv in den Betrieb ein und tut es halbherzig: Die Risikomarkierung hält die Erfüllung an, ohne jemanden zu informieren — dann liegt die Bestellung. Der dritte ist die Tarifgrenze, die wir dreimal erwähnt haben und die trotzdem übersehen wird: Der HTTP-Aufruf ist eingeplant, der Tarif erlaubt ihn nicht.

12:11 Und der vierte ist ein Organisationsfehler: Alle drei Workflows laufen auf denselben Verantwortlichen zu.