Der Happy Path lügt: Warum No-Code-Automatisierungen an Edge Cases zerbrechen

Der Happy Path lügt

Im November rief mich ein Kunde an. Eine Versandhandelsfirma, drei Mitarbeiter im Backoffice, etwa 40.000 Bestellungen im Jahr. Sein Problem: das Lager hatte 312 Kisten gepackt und versandt, die nie hätten verschickt werden dürfen. Stornierte Bestellungen, Adressfehler, doppelte Buchungen. Schaden in einer Nacht: knapp 18.000 Euro Rücksendungen plus zwei Tage Aufräumen.

Die Automatisierung lief seit acht Monaten ohne Probleme. Eingehende Bestellungen aus dem Shop, Validierung, Übergabe an die Lager-Software, Versandetikett, Statusupdate ans Kundensystem. Sieben Schritte, gut sichtbar in der Make-Oberfläche, ein Mitarbeiter hatte sie gebaut und stolz präsentiert.

Was war passiert? Der Shop-Anbieter hatte ein Update ausgerollt. Stornierungen sendeten jetzt einen zusätzlichen Webhook, einen "order.cancelled" Event, der vorher nicht existiert hatte. Der Workflow filterte auf "order.status == created". Das war immer noch wahr, weil die Stornierung als nachgelagerter Event kam, der die Order-Tabelle nicht zurücksetzte. Die Filter-Bedingung sah korrekt aus, war aber jetzt unvollständig. Acht Monate stabiler Lauf, dann ein API-Update, und plötzlich liefen 312 Stornierungen durch das System wie normale Bestellungen.

Niemand hatte das jemals getestet. Warum auch? Wenn alles funktioniert, testet man es nicht.

Diese Geschichte ist nicht ungewöhnlich. Sie ist das Standardmuster für Automatisierungen, die in Produktion sterben. Der Happy Path funktioniert, oft jahrelang, dann passiert irgendwo am Rand etwas, das niemand vorhergesehen hat, und die Automatisierung tut weiter, was sie immer getan hat. Sie erkennt nicht, dass die Welt sich verändert hat.

Warum der Happy Path nur 20 Prozent der Arbeit ist

Wenn ich No-Code-Workflows in Unternehmen review, sehe ich denselben Aufbau. Drei bis sieben Module, eine logische Sequenz, vielleicht eine Verzweigung. Das ist der Happy Path: die Welt, in der die Daten so aussehen wie geplant, die APIs antworten wie erwartet, und die Reihenfolge stimmt.

Der Happy Path ist 20 Prozent der Arbeit. Die anderen 80 Prozent sind die Frage, was passiert, wenn er nicht eintritt. Diese 80 Prozent sehen die meisten Workflow-Bauer nie, weil ihre Tests nur den Happy Path abdecken. Sie senden eine Test-Bestellung mit allen Feldern korrekt gefüllt, der Workflow läuft durch, und dann gilt er als fertig.

Das Problem: in Produktion kommen die Edge Cases. Sie kommen selten, vielleicht 1 von 1000 Durchläufen, aber sie kommen. Und wenn sie eine kritische Operation auslösen, eine Rechnung, einen Versand, eine Buchung, kann ein einziger Edge Case mehr Schaden anrichten als der Happy Path Wert geschaffen hat.

Das ist die Asymmetrie, die viele unterschätzen. Eine Automatisierung, die 99,5 Prozent richtig läuft, klingt gut. 99,5 Prozent von 40.000 Bestellungen pro Jahr sind 200 Fehler. Wenn jeder dieser Fehler einen Versand auslöst, der nicht hätte sein dürfen, sind das 200 Rücksendungen pro Jahr, die niemand auf dem Schirm hat.

Die sieben Kategorien von Edge Cases

In meiner Arbeit habe ich gelernt, dass Edge Cases sich gruppieren lassen. Wer diese Kategorien kennt, kann beim Bauen schon dagegen prüfen.

1. Leere oder fehlende Daten. Eine Suchabfrage liefert null Ergebnisse, ein Feld ist leer, das vorher immer gefüllt war, eine Liste enthält ein Element weniger als erwartet. Der Workflow nimmt an, dass mindestens ein Element existiert, und greift auf items[0] zu. Das wirft einen Fehler, der oft leise als Warnung durchläuft, oder schlimmer, das Modul bekommt einen leeren String und sendet ihn weiter, und plötzlich steht in der CRM-Notiz "Kunde: ". Das passiert öfter, als man glaubt.

2. Doppelte Trigger. Webhooks haben Retries. Webhooks haben Bugs. Webhooks haben Race Conditions. Ein Trigger, der zweimal ausgelöst wird, ist kein Sonderfall, sondern Normalbetrieb. Wer keine Idempotenz baut, riskiert doppelte Datensätze, doppelte Rechnungen, doppelte E-Mails. Die Idempotenz-Frage gehört in den ersten Sketch jeder Automatisierung, nicht erst in das Refactoring nach dem ersten Vorfall.

3. Schema-Änderungen. APIs ändern sich. Felder werden umbenannt, hinzugefügt, deprecated. Manchmal kündigt der Anbieter es 90 Tage vorher an, manchmal passiert es ohne Kommunikation, weil ein Update am Backend etwas geändert hat. Die Workflows, die auf diese Felder zugreifen, brechen. Im besten Fall mit einem klaren Fehler, im schlechtesten mit einer stillen falschen Annahme: das Feld ist leer, also wird der Default-Wert genommen, und der Default war "Premium-Kunde".

4. Rate Limits. Jede API hat Limits. Manche dokumentieren sie, manche nicht. Manche Plattformen haben unterschiedliche Limits für unterschiedliche Endpunkte. Eine Massen-Operation, die 5.000 Datensätze synchronisieren soll, läuft 4.200 durch und bekommt dann 429 Too Many Requests. Wenn der Workflow keine Backoff-Logik hat, hängt er, bricht ab, oder ignoriert die letzten 800 still.

5. Auth-Probleme. OAuth-Tokens laufen ab. API-Keys werden rotiert. Service-Accounts werden gelöscht. Wenn ein Workflow seit drei Monaten nur dann läuft, wenn ein neuer Lead kommt, und der Token vor zwei Wochen abgelaufen ist, hat er zwei Wochen lang nichts getan. Niemand hat es bemerkt, weil niemand alarmiert wurde. Das ist ein klassisches Beispiel dafür, warum Automatisierung immer Monitoring braucht, nicht nur Logging.

6. Race Conditions und parallele Edits. Zwei Workflows greifen auf denselben Datensatz zu. Workflow A liest, modifiziert, schreibt zurück. Zwischen Lesen und Schreiben hat Workflow B den Datensatz auch verändert. Das Resultat: Workflow Bs Änderung wird überschrieben. In No-Code-Plattformen gibt es selten Locking-Mechanismen, weil das Konzept den meisten Bauern fremd ist. Sie merken es erst, wenn die Daten nicht mehr stimmen.

7. Encoding und Format. Umlaute in alten Systemen, Emojis in neuen, BOM in CSVs, Zeilenumbrüche in CSV-Feldern, Komma vs Punkt als Dezimaltrenner, Datumsformate (DD.MM.YYYY vs ISO), Zeitzonen in Timestamps. Eine Automatisierung, die in Deutschland gebaut wurde, läuft anders, wenn der erste Kunde aus den USA kommt. Eine Automatisierung, die mit der Test-Adresse "Müller" funktioniert hat, kann mit "Søren Bjørn" stolpern.

Sieben Kategorien, jede mit Dutzenden Unterfällen. Wer alle bedacht hat, ist fertig. Wer nicht, hat eine tickende Bombe gebaut.

Warum No-Code das Problem verschärft

In klassischer Softwareentwicklung gibt es Werkzeuge gegen Edge Cases. Type-Systeme, Tests, Linter, Code Reviews. Ein Junior-Entwickler bekommt im Pull Request einen Kommentar: "Was passiert hier, wenn das Array leer ist?". Der Pattern-Match-Check zwingt zur Antwort.

In No-Code fehlt das alles. Make, Zapier und n8n sind grafische Tools, die optimiert sind, schnell etwas zu bauen, das funktioniert. Sie sind nicht optimiert, dabei zur Defensive zu zwingen.

Drei konkrete Effekte:

Visuelle Workflows verbergen Komplexität. Ein Diagramm mit fünf Kästchen sieht einfacher aus als 500 Zeilen Code, das auch nur fünf Operationen macht. Die Einfachheit ist optisch, nicht semantisch. Die Edge Cases sind dieselben, aber sie verstecken sich in Filter-Bedingungen und Modul-Optionen, die niemand näher liest.

Fehler-Handling ist optional. In Make muss man jedes Modul aktiv mit einer Fehlerroute versehen. In Zapier muss man Path-by-Path Checks bauen. Standardmäßig macht keine dieser Plattformen etwas Sinnvolles, wenn ein Schritt scheitert. Wer vergisst, eine Fehlerroute einzubauen, hat einen Workflow, der bei jedem Edge Case still stirbt oder Fehlermeldungen schluckt.

Tests existieren nicht. Es gibt keine Unit-Tests für Make-Szenarien. Es gibt keine Continuous Integration, die jeden Push gegen 50 Testfälle laufen lässt. Es gibt nur die Test-Funktion, die einen Durchlauf simuliert, mit den Daten, die man gerade in der Hand hat. Wer also einen Workflow baut, baut ihn gegen genau einen Datenpunkt, und nimmt an, dass die anderen 999.999 ähnlich aussehen.

Das Resultat: No-Code-Automatisierungen sind Edge-Case-fragiler als geschriebene Software. Der Grund liegt nicht in den Plattformen, sondern in der Bauer-Kultur. In Code-Reviews stellt jemand die Frage. In Make stellt sie niemand.

Was richtige Edge-Case-Behandlung bedeutet

Die gute Nachricht: man kann gegen Edge Cases bauen. Es ist Mehraufwand, vielleicht 30 bis 50 Prozent mehr Zeit pro Workflow, aber es ist machbar. Die schlechte Nachricht: die meisten Bauer-Teams investieren diese Zeit nicht, weil sie den Aufwand nicht sehen, bis es zu spät ist.

Hier sind sechs Disziplinen, die wirklich helfen.

Validieren am Eintrittspunkt. Bevor irgendein Modul Daten verarbeitet, prüfen Sie sie. Ist das Pflichtfeld da? Hat das Datum das richtige Format? Ist der Betrag positiv? Ist die E-Mail-Adresse plausibel? Diese Checks sehen pedantisch aus, fangen aber 70 Prozent aller Edge Cases ab. In Make machen Sie es mit einem Filter direkt nach dem Trigger, in n8n mit einer Code-Node, in Zapier mit einem Filter und Lookup-Tabellen.

Idempotenz-Schlüssel mitführen. Wenn der Trigger eine ID hat (Order-ID, Lead-ID, Webhook-ID), prüfen Sie, ob diese ID schon einmal verarbeitet wurde. Eine kleine Datenbank-Tabelle oder ein Airtable, das diese IDs sammelt, reicht. Wer schon einmal gelaufen ist, läuft nicht noch einmal. Das verhindert die meisten Doppel-Buchungen, doppelten E-Mails und doppelten Rechnungen.

Fehlerrouten für jedes Modul. Wenn etwas schiefgeht, muss klar sein, was passiert. Geht der Fehler in einen Slack-Kanal? Wird er in einer Tabelle gesammelt? Wird der Workflow rückabgewickelt? Die Antwort darf nicht "weiß ich nicht" sein. In Make ist das ein Right-Click auf das Modul plus Add Error Handler. In n8n bauen Sie einen OnError-Branch. Es kostet zehn Minuten pro Modul.

Monitoring, nicht nur Logging. Logs sind Daten, Monitoring ist Aufmerksamkeit. Wenn ein Workflow in den letzten 24 Stunden fünf Fehler produziert hat, müssen Sie es wissen, ohne dass Sie es nachschauen müssen. Eine wöchentliche Stand-up Mail, ein Slack-Channel mit Alerts, ein Dashboard, das jeden Morgen kurz angesehen wird, sind Mindeststandard.

Schemata explizit annehmen. Statt blind auf items[0].properties.email zuzugreifen, prüfen Sie: gibt es items? Gibt es properties? Gibt es email? Das sieht überflüssig aus, ist aber der Unterschied zwischen einem klaren Fehler und einer stillen falschen Annahme. In Modulen mit "if-empty"-Optionen nutzen Sie sie. In Modulen ohne sie bauen Sie Filter davor.

Test-Daten gegen Produktionsdaten testen. Bevor ein Workflow live geht, lassen Sie ihn gegen mindestens zehn echte historische Beispiele laufen. Idealerweise sortiert nach Häufigkeit: die fünf häufigsten Datenmuster, dann fünf seltene oder bekannte Edge Cases. Zwei Stunden, aber Sie finden 60 Prozent der Fehler vor dem Live-Gang statt nach.

Diese sechs Disziplinen klingen nach viel. Sind sie auch. Aber jede einzelne ist billiger als ein einziger Vorfall in Produktion, der Daten korrumpiert, Kunden verärgert oder Geld kostet.

Die Mentalität, die fehlt

Ich glaube, der eigentliche Kern des Problems ist kultureller Natur, nicht technischer. No-Code wird oft verkauft mit dem Versprechen "schnell und einfach". Das stimmt für den Happy Path. Es stimmt nicht für Produktivbetrieb.

Wer einen Workflow baut, der eine kritische Operation auslöst, baut Software. Egal ob das Tool grafisch ist oder Code. Software bedeutet: man trägt Verantwortung für das, was passiert, wenn die Welt nicht so aussieht wie geplant. Man kann nicht "nur den Happy Path bauen" und sagen, der Rest sei nicht das eigene Problem.

Diese Mentalität fehlt in vielen No-Code-Teams. Sie kommt aus der klassischen Softwareentwicklung und muss bewusst gelernt werden. Sie heißt: defensives Denken, Paranoia über Inputs, Pessimismus über externe Systeme.

Konkret bedeutet das, vor jedem Schritt zu fragen:

• Was, wenn dieser Wert leer ist?
• Was, wenn diese API nicht antwortet?
• Was, wenn dieser Trigger zweimal kommt?
• Was, wenn die Reihenfolge anders ist?
• Was, wenn jemand denselben Datensatz parallel ändert?
• Was, wenn dieses Feld plötzlich anders heißt?
• Was, wenn der Token abgelaufen ist?

Das sind keine theoretischen Fragen. Jede einzelne ist mir in den letzten zwei Jahren bei Kunden begegnet. Manchmal mehrfach.

Wann sich der Aufwand lohnt

Nicht jede Automatisierung muss diese Disziplin haben. Ein Workflow, der jeden Montag eine interne Status-Mail an drei Personen sendet, kann ruhig kaputt gehen, jemand merkt es. Die Frage, wie viel Edge-Case-Behandlung notwendig ist, hängt von der Konsequenz des Fehlers ab.

Vier Fragen, die ich bei jedem Projekt stelle:

Was passiert, wenn dieser Workflow falsch läuft? Antworten reichen von "egal, nichts" bis zu "wir verlieren Kunden, Geld oder Compliance". Je weiter rechts, desto mehr Defensive.

Wie viele Datensätze laufen pro Tag durch? Bei zehn Datensätzen pro Tag merken Sie Probleme schnell. Bei zehntausend nicht. Hohe Volumina brauchen automatische Defensive, weil manuelle Kontrolle nicht skaliert.

Hängen andere Systeme oder Personen davon ab? Ein Workflow, der nur eine Datei kopiert, ist isoliert. Ein Workflow, der die Lager-Software triggert, ist Teil einer Pipeline. Pipelines kaskadieren Fehler.

Gibt es regulatorische oder finanzielle Folgen? Eine fehlerhafte Buchung in DATEV ist eine andere Klasse als ein fehlerhafter Slack-Post. Compliance verändert die Risikoabwägung.

Wer diese Fragen ehrlich beantwortet, weiß, wo Disziplin gebraucht wird und wo man sie sich sparen kann. Aber: viele Workflows, die als "klein und harmlos" beginnen, wachsen über Monate in kritische Pfade hinein, ohne dass jemand die Defensive nachträglich einbaut. Das ist wie Hausbau ohne Fundament: solange das Haus klein ist, geht es. Wenn ein zweites Stockwerk dazukommt, fällt es um.

Die ehrliche Empfehlung

Wenn Sie No-Code-Automatisierungen in Ihrem Unternehmen haben, die kritisch laufen, machen Sie diese Woche eine Übung. Nehmen Sie sich drei Workflows. Setzen Sie sich mit der Person hin, die sie gebaut hat. Stellen Sie für jeden die sieben Kategorien-Fragen oben. Notieren Sie ehrlich, gegen wie viele die Workflows abgesichert sind.

Wenn die Antwort über 50 Prozent liegt, herzlichen Glückwunsch. Sie sind besser als der Durchschnitt.

Wenn sie unter 50 Prozent liegt, haben Sie eine Liste mit konkreten Lücken. Diese Lücken sind Ihre Roadmap. Pro Workflow vielleicht ein bis zwei Tage Aufräum-Arbeit, oft weniger. Verteilt über die nächsten zwei Quartale ist das machbar.

Stabilität ist die offensichtliche Folge dieser Arbeit. Skalierbarkeit ist die unsichtbare. Eine Automatisierung, die gegen Edge Cases gehärtet ist, kann das Volumen verdoppeln, ohne dass Sie eingreifen müssen. Eine fragile bricht beim ersten Wachstumsschub. Der Unterschied liegt nicht im Tool, sondern in der Disziplin beim Bauen.

Der Kunde mit den 312 fehlerhaften Versendungen hat zwei Wochen lang aufgeräumt. Danach haben wir den Workflow überarbeitet. Validation am Eintritt, Idempotenz mit Order-ID, Fehlerroute zu Slack, Monitoring-Dashboard. Acht Stunden Arbeit. Seit acht Monaten kein einziger fehlerhafter Versand mehr. Das ist die Differenz.

Wer wissen möchte, wo die kritischen Edge Cases in den eigenen Workflows liegen, bekommt im kostenlosen Automations-Check in etwa 30 Minuten eine ehrliche Einschätzung mit konkreten Schwachstellen.