Shopify Flow vs. Custom-Automatisierung: Die ehrliche Entscheidungshilfe

Ein Händler schrieb mir kürzlich: "Wir haben 14 Flows gebaut und trotzdem tippt mein Team jeden Morgen Daten von Hand ab." Das ist kein Einzelfall — und es ist kein Versagen von Flow. Es ist das Ergebnis einer fehlenden Entscheidungsgrundlage: Für welche Prozesse ist Flow das richtige Werkzeug, und ab welchem Punkt brauchen Sie Custom-Code?

Shopify Flow ist seit 2023 in allen Plänen ab Basic kostenlos enthalten. Gleichzeitig hat Shopify 2025 mit dem verbesserten Send HTTP Request-Block und der Sidekick-KI die Grenzen von Flow erheblich verschoben. Was gestern noch eine Custom-App erforderte, lässt sich heute manchmal mit einem einzigen Flow-Workflow lösen — und umgekehrt.

Dieser Artikel ist keine Werbung für Custom-Entwicklung. Er ist eine ehrliche Analyse mit einer konkreten Entscheidungsmatrix, damit Sie nicht zu früh migrieren und nicht zu lange warten.

Was Shopify Flow 2025/2026 wirklich kann

Flow hat in den letzten 18 Monaten enorme Sprünge gemacht. Wer den Stand von 2023 im Kopf hat, unterschätzt das Tool massiv.

Das neue Send HTTP Request — der Game-Changer

Der wichtigste Update: Der Send HTTP Request-Block gibt seit 2025 die vollständige Response an den Workflow zurück. Das klingt technisch, bedeutet praktisch aber: Flow kann jetzt mit externen APIs bidirektional kommunizieren.

Workflow-Schritt 1:  Trigger (z. B. orders/create)
Workflow-Schritt 2:  Send HTTP Request → POST an Ihr CRM
Workflow-Schritt 3:  Run Code → JSON.parse(sendHttpRequest.body)
Workflow-Schritt 4:  Condition → if (parsedData.risk_score > 0.8)
Workflow-Schritt 5:  Action → Order on hold + Tag setzen

Das ist ein fundamentaler Unterschied zu früher: Sie können externe Daten abrufen, verarbeiten und für Conditions nutzen — alles innerhalb eines Flows. Secrets wie API-Tokens werden verschlüsselt gespeichert und tauchen in Logs nicht auf.

Wichtig: Dieser Feature ist nur in den Plänen Grow, Advanced und Plus verfügbar. Basic-Händler haben keinen Zugriff auf Send HTTP Request.

Was Flow heute zuverlässig löst

Die 6 harten Grenzen von Shopify Flow

Flow ist mächtig — aber es gibt Grenzen, die sich nicht durch neue Features wegdiskutieren lassen. Diese sechs Punkte sind architekturell bedingt.

1. Kein State-Management über Runs hinweg

Jeder Flow-Run ist stateless. Er weiß nicht, was beim letzten Mal passiert ist. Es gibt keine persistierten Variablen, keine Zähler, keine Verlaufslogik.

Konsequenz: "Wenn ein Kunde drei Monate nicht bestellt hat, sende eine E-Mail" ist mit Flow nicht direkt abbildbar. Der Workaround — Datum in ein Kunden-Metafield schreiben — funktioniert, skaliert aber schlecht, sobald Sie fünf verschiedene Zeitstempel tracken müssen.

2. Keine Array-Iteration

Flow kann prüfen, ob ein einzelnes Feld einen Wert hat. Über eine Liste von Line-Items iterieren, Gewichte aufsummieren, Kategorien zählen — das geht nicht.

Konsequenz: "Wenn mehr als drei verschiedene Produktkategorien in der Bestellung sind UND das Gesamtgewicht über 30 kg liegt → Speditionsversand buchen" ist für Flow zu komplex.

3. Run Code ohne HTTP-Calls

Die Run Code Blocks in Flow unterstützen ECMA2020 JavaScript — aber explizit ohne fetch() oder andere HTTP-Calls. Sie können Daten transformieren und berechnen, aber keine eigenen externen Requests abfeuern.

// Was in Run Code geht:
const data = JSON.parse(input.body);
const nettoPreis = (data.bruttoPreis / 1.19).toFixed(2);
output.nettoPreis = nettoPreis;
 
// Was NICHT geht:
const response = await fetch('https://mein-erp.de/api/preise'); // Fehler!

4. Keine transaktionale Fehlerbehandlung

Wenn Schritt 3 eines Flows fehlschlägt, wurden Schritte 1 und 2 bereits ausgeführt — und bleiben ausgeführt. Es gibt kein Rollback, keine automatischen Retries mit Backoff, keine Alternative-Pfade bei Fehlern.

Für kritische Prozesse — Zahlungsabgleich, Bestandssynchronisation, Fulfillment-Routing — ist das ein Dealbreaker. Ein halbautomatisierter, inkonsistenter Zustand ist oft schlimmer als gar keine Automatisierung.

5. Keine komplexen Berechnungen

Run Code ermöglicht einfache Transformationen, aber Flow hat ein Input-Limit von 5.000 Zeichen pro Daten-Query. Komplexe Berechnungen über viele Datenpunkte — z. B. Deckungsbeitragsanalyse pro Bestellung auf Basis von ERP-Einkaufspreisen — sprengen das schnell.

6. Store-Isolation

Flow arbeitet innerhalb eines einzigen Stores. Kein Cross-Store-Sync, keine zentrale Logik über mehrere Shopify-Instanzen, kein übergreifendes Reporting. Für Multi-Store-Setups (B2B + D2C, mehrere Länder-Stores) ist Flow strukturell die falsche Wahl.

Entscheidungs-Framework: Flow oder Custom?

Die 5-Fragen-Checkliste

Beantworten Sie diese fünf Fragen — und Sie wissen, ob Flow reicht:

1. Brauchen Sie Daten von außerhalb Shopifys?

   ERP, PIM, CRM, externe Preis-APIs, Compliance-Datenbanken. Wenn ja: Flow kann via Send HTTP Request (Grow+) Daten abrufen und zurückbekommen. Wenn die Logik nach dem API-Call komplex wird oder Retry-Sicherheit nötig ist: Custom.

2. Müssen Sie über Listen iterieren oder aggregieren?

   Alle Line-Items einer Bestellung durchgehen, Gesamtgewichte berechnen, Varianten-Bestände summieren. Wenn ja: Custom. Flow hat keine Schleifen.

3. Ist Echtzeit-Reaktion geschäftskritisch?

   Checkout-Anpassungen, Preisreservierungen, synchrone API-Calls unter 500ms. Flow verarbeitet Events mit einer Queue — typisch wenige Sekunden, bei Lastspitzen (Black Friday) bis zu 5–15 Minuten. Wenn Timing kritisch: Custom.

4. Muss der Prozess zu 99,9 % zuverlässig laufen?

   Zahlungsabgleich, steuerrelevante Datensätze, Fulfillment-Routing mit Haftungskonsequenzen. Wenn ja: Custom mit Retry-Logik, Monitoring und Alerting.

5. Brauchen Sie historische Daten oder State über mehrere Runs?

   Kundenhistorie, Trendanalysen, Zähler, "zuletzt ausgeführt am". Wenn ja: Metafield-Workaround nur für einfache Fälle akzeptabel — ansonsten Custom.

Auswertung:

• 0–1× "Ja": Flow ist die richtige Wahl. Nutzen Sie es.
• 2–3× "Ja": Hybrid-Ansatz prüfen (nächster Abschnitt).
• 4–5× "Ja": Custom-Automatisierung ist die saubere Investition.

Die Entscheidungsmatrix

Der Hybrid-Ansatz: Flow triggert, Custom verarbeitet

Die klügste Strategie für wachsende Shops ist oft kein "entweder oder", sondern eine klare Aufgabenteilung.

Architektur: Flow als Vorfilter

Shopify Event
      │
      ▼
┌─────────────┐    Tag/Metafield     ┌──────────────────────┐
│ Shopify Flow │ ──────────────────▶ │ Custom Middleware     │
│             │                      │                      │
│ Einfache    │  ◀────────────────── │ Komplexe Logik:      │
│ Checks +    │    Metafield/Tag     │ • ERP-Sync           │
│ Tagging     │                      │ • Preisberechnung    │
└─────────────┘                      │ • Retry-Logik        │
                                     │ • Reporting          │
                                     └──────────────────────┘

Konkretes Beispiel — B2B-Bestellverarbeitung:

Flow übernimmt:

• Trigger: orders/create
• Condition: Customer-Tag enthält "b2b"
• Action: Order-Tag "needs-b2b-processing" setzen + Slack-Notification

Custom-Middleware übernimmt:

• Webhook orders/create empfangen
• B2B-Preise aus ERP-Vertragssystem laden
• Rechnung mit Custom-Template generieren
• Fulfillment an Spedition übermitteln
• Bei Fehler: Retry mit Exponential Backoff, Alerting an Ops-Team

Vorteile dieser Aufteilung:

• Marketing-Team pflegt Flows eigenständig
• Technik-Team pflegt Custom-Logik
• Einfache Regeländerungen ohne Deploy-Zyklus
• Nur das Komplexe wird custom gebaut — das senkt Kosten deutlich

Kosten ehrlich gerechnet

Was Shopify Flow kostet

Flow selbst ist kostenlos — aber Vorsicht: Der Send HTTP Request-Block erfordert mindestens den Grow-Plan (~105 €/Monat statt 39 €/Monat für Basic). Wenn Sie diesen Schritt für externe Integrationen brauchen, muss die Plandifferenz in die Kostenrechnung.

Zusätzlich: Connector-Apps für Tools wie Klaviyo, Gorgias oder ReCharge können 0–100 €/Monat kosten.

Was Custom-Automatisierung kostet

Break-Even-Rechnung

Manuelle Arbeit, die wegfällt:   X Stunden/Monat × Stundensatz
+ App-Kosten, die entfallen:     Y €/Monat
+ Vermiedene Fehler/Ausfälle:    Z €/Monat
────────────────────────────────────────────
= Monatliche Einsparung
 
Investition ÷ Einsparung = Break-Even in Monaten

Realistisches Beispiel aus einem Kundenprojekt:

• 2 Mitarbeiter × 5 h/Monat manueller Sync → 10 h × 40 €/h = 400 €/Monat
• 3 Automatisierungs-Apps à durchschnittlich 50 € → 150 €/Monat
• 2 Support-Aufwände/Monat durch Flow-Fehler → 80 €/Monat
• Monatliche Einsparung: 630 €

Bei einer Custom-Investition von 5.500 € liegt der Break-Even bei unter 9 Monaten. Ab Monat 10 sparen Sie 630 € netto jeden Monat.

Die versteckte Kostenfalle: Plugin-Stacking

Was ich bei vielen Shops sehe: Flow reicht nicht, also kommen Zapier (ab 20 €/Monat), Make (ab 10 €/Monat) und drei weitere Apps dazu. Plötzlich zahlen Sie 200–400 € monatlich für ein Flickwerk, das niemand mehr versteht und das trotzdem Lücken hat.

In diesem Szenario ist Custom nicht nur besser — es ist auch günstiger.

Praxis-Szenarien mit klarer Empfehlung

Grenzfall: Dynamische Preisanpassung — Wenn Sie täglich externe Preisquellen abfragen und Produktpreise anpassen möchten, brauchen Sie Custom. Flow kann via HTTP zwar Preisdaten abrufen, aber keine Schleife über alle Produkte laufen und Preise in Bulk aktualisieren.

Grenzfall: Compliance-Automatisierung — GPSR, WEEE und VerpackG erfordern komplexe, regelbasierte Logik mit Datenbank und dynamischem Regelwerk. Flow kommt hier schnell an seine Grenzen — nicht wegen der API, sondern wegen der Conditions-Komplexität.

Weiter vertiefen: Wie konkrete Custom-Automatisierungen technisch aussehen — inklusive Webhook-Handling, Queuing und Fehlerbehandlung — beschreibe ich in Shopify Automatisierung: 10 Prozesse, die kein Plugin lösen kann.

Migrationsstrategie: Von Flow zu Custom

Wenn Sie entschieden haben, dass Custom der richtige Weg ist — hier ein pragmatischer Fahrplan ohne großen Riss:

1. Audit (1 Woche)

   Alle bestehenden Flows dokumentieren. Manuelle Workarounds identifizieren. Plugin-Kosten auflisten. Kritische Prozesse nach Schmerzgrad priorisieren — nicht nach technischer Eleganz.

2. Hybrid-Start (2–4 Wochen)

   Die zwei bis drei schmerzhaftesten Prozesse als Custom implementieren. Flow für alles andere beibehalten. Monitoring und Logging einrichten. Erst dann weiter.

3. Iterative Erweiterung (fortlaufend)

   Weitere Prozesse schrittweise migrieren, wenn der Business Case stimmt. Flow-Workflows, die zuverlässig funktionieren, grundsätzlich behalten. Nicht migrieren, was funktioniert.

Der wichtigste Grundsatz: Ein Flow, der seit 6 Monaten zuverlässig Kunden taggt, muss nicht in eine Custom-App migriert werden — nur weil es "professioneller" klingt. Migrieren Sie nur, was echte Probleme verursacht oder echte Kosten erzeugt.

Fazit: Flow ist mächtig — aber kein Allheilmittel

Shopify Flow hat sich 2025 erheblich weiterentwickelt. Mit dem verbesserten Send HTTP Request-Block und der Sidekick-KI für Workflow-Erstellung deckt es heute Szenarien ab, für die vor zwei Jahren noch Custom-Code nötig war. Nutzen Sie es — konsequent und frühzeitig.

Gleichzeitig haben sich die architekturellen Grenzen nicht verschoben: kein State-Management, keine Array-Iteration, keine transaktionale Fehlerbehandlung, keine Multi-Store-Logik. Wenn Sie sich in diesen Bereichen bewegen, kostet das Festhalten an Flow mehr als die Custom-Investition.

Die ehrliche Empfehlung: Starten Sie mit Flow. Nutzen Sie die 5-Fragen-Checkliste, wann immer Sie einen neuen Prozess automatisieren wollen. Und wenn Custom nötig ist, machen Sie es sauber — mit Fehlerbehandlung, Monitoring und dem Hybrid-Ansatz, der Flow für das behält, was es gut kann.

Häufige Fragen

Weiterführende Artikel

• Shopify Automatisierung: 10 Prozesse, die kein Plugin lösen kann – Konkrete Beispiele für komplexe Workflows, die Flow überfordern, mit echtem Code.
• Mechanic: Der Shopify-Automatisierer zwischen Flow und Custom App – Wann Mechanic die goldene Mitte zwischen Flow und Custom-Entwicklung ist.
• Shopify ERP-Integration: Der komplette Guide – Wie Custom-Middleware technisch aussieht: Webhook-Handling, Queuing und Fehlerbehandlung im Detail.