Wie ein Make-Workflow versehentlich 4.800 Kunden eine Test-Mail schickte
Ein Newsletter-Workflow in Make schickt versehentlich 4.800 Kunden eine Lorem-Ipsum-Mail. Warum die Trennung zwischen Test und Echtbetrieb in No-Code-Automatisierungen schwächer ist, als die meisten denken, und welche fünf Disziplinen das verhindern.
Wie ein Make-Workflow versehentlich 4.800 Kunden eine Test-Mail schickte
Vor zwei Jahren rief mich an einem Mittwochmorgen ein Marketing-Leiter an. Etwas in seiner Stimme war nicht in der gewohnten Tonlage. "Wir haben gerade 4.800 Kunden eine E-Mail mit dem Subject 'TEST: BITTE IGNORIEREN' geschickt", sagte er. "Inhalt: Lorem Ipsum."
Er hatte einen neuen Newsletter-Workflow in Make gebaut. Die Logik mit zehn Test-Empfängern validiert. Auf "Workflow aktivieren" geklickt. Was er nicht gesehen hatte: der Empfängerfilter zeigte auf eine Liste, die ein Kollege drei Wochen zuvor umkonfiguriert hatte. Aus zehn Test-Adressen war zwischenzeitlich der komplette Newsletter-Verteiler des Unternehmens geworden.
Der Trigger feuerte. 4.800 E-Mails gingen raus. Lorem-Ipsum-Inhalt, echter Absender, echte Postfächer. Der Schaden war begrenzt: 200 verwirrte Antworten, 30 Beschwerden, ein paar Abmeldungen. Aber so etwas brennt sich in das Gedächtnis eines Marketing-Teams.
Diese Geschichte ist nicht die Ausnahme. Sie ist die typische Variante eines Problems, das in fast jeder Automatisierung schlummert: die Trennung zwischen Test und Echtbetrieb ist viel weicher, als die meisten Plattformen suggerieren.
Was visuelle Builder verschweigen
Wer Software entwickelt, kennt den Rhythmus: Entwicklung, Staging, Produktion. Drei getrennte Datenbanken, drei URLs, drei Anmeldungen. Was im Test passiert, kann den Echtbetrieb nicht erreichen.
In Zapier, Make, n8n oder Activepieces gibt es das nicht. Ihr Test-Workflow hängt am gleichen CRM, am gleichen Mailserver, am gleichen Slack-Workspace wie der produktive. Wenn Sie versehentlich live gehen, gibt es keinen Sicherheitsgurt.
Das ist Absicht. Diese Plattformen sind dafür gebaut, dass jemand ohne IT-Hintergrund in zwei Stunden etwas zusammenklicken kann. Drei getrennte Umgebungen wären eine Hürde, die das Versprechen der Plattformen aushebeln würde. Stattdessen liegt die Verantwortung bei Ihnen: Sie sind der Sicherheitsgurt.
Den meisten ist nicht klar, dass sie diese Verantwortung tragen. Bis etwas explodiert.
Drei Wege, wie ein Workflow vom harmlosen Test zum Vorfall wird
In der Praxis sehe ich immer wieder dieselben drei Muster.
Falsche Liste, richtiger Workflow. Genau das, was meinem Kunden passiert ist. Ein Filter oder ein Listenverweis, der in der Testphase auf "klein" zeigte, zeigt im Echtbetrieb auf "alle". Der visuelle Editor flaggt das nicht. Es sieht aus wie ein Parameter, nicht wie eine geschäftskritische Entscheidung.
Test-Läufe, die echte Systeme treffen. Sie testen einen Workflow mit dem ersten Datensatz aus Ihrer Kundendatenbank. Der Test schickt eine echte E-Mail, weil das Mail-Modul nicht weiß, dass es ein Test ist. Der Kunde bekommt um 23 Uhr eine seltsame Bestätigungsmail für etwas, was er nie angefragt hat.
Webhooks, die niemand abgekoppelt hat. Sie haben einen alten Workflow stillgelegt und einen neuen gebaut. Der alte ist deaktiviert, der neue ist aktiv. Was Sie übersehen haben: das CRM schickt seine Webhooks weiter an den alten Endpunkt, weil dort niemand den Webhook gelöscht hat. Drei Tage lang verarbeitet niemand die Daten, weil beide Zustände in der Oberfläche "okay" aussehen.
Was wirklich hilft
Diese Probleme lassen sich nicht durch mehr Aufmerksamkeit lösen. Sie sind strukturell. Wer sie vermeiden will, baut bestimmte Disziplinen in den eigenen Workflow-Aufbau ein.
Test-Empfänger als Konstanten in den Workflow schreiben. Nicht eine Liste auswählen, die später jemand umkonfigurieren könnte. Stattdessen drei E-Mail-Adressen direkt im Workflow als feste Werte hinterlegen. Wenn der Workflow live geht, werden diese Adressen explizit entfernt und durch die produktive Logik ersetzt. Das ist ein bewusster Schritt, nicht ein stiller Wechsel eines Filters.
Sichtbares "Modus"-Flag. Bauen Sie in jeden Workflow eine Variable ein, die "TEST" oder "PROD" enthält. Im Test-Modus bekommt jede ausgehende Nachricht ein "[TEST]"-Präfix oder läuft auf eine interne Adresse. Im Prod-Modus läuft sie normal. Das Flag steht oben im Workflow, sichtbar. Wer ihn schaltet, weiß, was er tut.
Sandbox-Konten für Drittsysteme nutzen. Salesforce, HubSpot und Stripe bieten Sandbox-Umgebungen. Nutzen Sie diese für Tests, nicht das produktive System. Bei Tools ohne Sandbox legen Sie ein zweites Konto an, das nur Test-Daten enthält.
Webhook-Endpunkte versionieren. Wenn Sie einen Workflow ablösen, ändern Sie die URL des neuen Endpunkts. Der alte Webhook im CRM zeigt dann ins Leere und produziert sichtbare Fehler. Das ist besser als ein stiller Push an einen deaktivierten Workflow.
Vor dem Go-Live: Empfängerliste ansehen. Bevor Sie einen Workflow scharf schalten, der etwas nach außen verschickt, lassen Sie sich die ersten zehn Empfänger zeigen. Nicht abstrakt, sondern als Liste mit Namen und Adressen. Wenn dort jemand steht, den Sie nicht erwartet haben, halten Sie an.
Der eigentliche Punkt
Test-Daten und Echtdaten in Automatisierungen sind kein technisches Problem. Sie sind ein Disziplinproblem.
In Code-basierter Software haben Sie eine Trennung, weil das Werkzeug Sie zwingt. In No-Code haben Sie keine, weil das Werkzeug Sie befreit. Beides hat seine Berechtigung. Aber wer mit No-Code arbeitet, muss diese Disziplin selbst aufbauen, sonst zahlt er sie irgendwann mit einer peinlichen E-Mail an mehrere tausend Kunden.
Wenn Sie Workflows bauen, die nach außen wirken (E-Mails, SMS, Posts, API-Aufrufe an externe Systeme), gehen Sie davon aus, dass Sie irgendwann einmal versehentlich live gehen. Der Test, ob Ihre Architektur das überlebt, ist nicht hypothetisch. Er ist eine Frage der Zeit.
Wer wissen möchte, wo die kritischen Übergänge zwischen Test und Echtbetrieb in den eigenen Automatisierungen liegen, bekommt im kostenlosen Automations-Check in etwa 30 Minuten ein klares Bild.