Make macht den Einstieg leicht, und genau deshalb entstehen schnell unübersichtliche Szenarien. Mit ein paar Regeln bleiben sie wartbar.
Klein und modular
Teilen Sie große Szenarien in mehrere kleine mit klarer Aufgabe. So lassen sich Fehler schneller finden und einzelne Teile ändern, ohne alles zu gefährden.
Sauber benennen
Geben Sie Szenarien und Modulen sprechende Namen. Eine kurze Beschreibung erklärt, wozu der Ablauf dient und wer dafür zuständig ist.
Fehlerpfade einbauen
Legen Sie für wichtige Module fest, was im Fehlerfall passiert. Melden Sie Probleme aktiv, statt sie nur im Verlauf zu protokollieren.
Verbrauch im Blick behalten
Ausführungen kosten Kontingent. Prüfen Sie, wie oft Szenarien laufen müssen, und filtern Sie möglichst früh, damit unnötige Schritte gar nicht erst ausgeführt werden.
Dokumentieren
Halten Sie fest, welche Zugänge genutzt werden und was bei Personalwechsel zu tun ist. Workflows sollten nicht an einem persönlichen Konto hängen.
Eine Struktur für mehrere Szenarien
Modulare Szenarien müssen auch zusammen verständlich bleiben. Bewährt hat sich die Trennung in drei Aufgaben: Ein Szenario nimmt Ereignisse an und prüft sie, ein weiteres führt die fachliche Verarbeitung aus, ein drittes kümmert sich um Benachrichtigungen. Die Übergabe kann über einen Webhook, einen Data Store oder eine vorhandene Datenbank erfolgen. Ein Beispiel: Ein Webformular meldet eine Anfrage, das erste Szenario prüft die Pflichtangaben und übergibt nur gültige Fälle an die Anlage im CRM.
Ordnen Sie zusammengehörige Szenarien zudem in Ordnern nach Fachbereich oder Prozess. Eine einheitliche Benennung nach dem Muster „Bereich, Auslöser, Ergebnis“ macht auch in einer langen Liste schnell sichtbar, was ein Szenario tut. Wenn mehrere Teams mit Make arbeiten, sollten Sie die Regeln einmal schriftlich festlegen, bevor jeder eine eigene Ordnung entwickelt.
Mehrfachläufe verkraften
Ein Szenario kann mitten im Lauf abbrechen, oder ein Auslöser kann dieselben Daten doppelt liefern. Prüfen Sie deshalb bei jedem schreibenden Schritt: Was passiert, wenn dieser Schritt ein zweites Mal läuft? Ein neuer Kontakt im CRM würde dann doppelt angelegt, eine Rechnung sogar doppelt erzeugt.
Abhilfe schafft eine eindeutige Kennung aus dem Ursprungssystem. Suchen Sie vor dem Anlegen, ob der Datensatz bereits existiert, und aktualisieren Sie ihn gegebenenfalls. Alternativ speichern Sie verarbeitete Kennungen in einem Data Store. Setzen Sie den Status eines Vorgangs erst am Ende auf „erledigt“, damit ein abgebrochener Lauf nicht fälschlich abgeschlossen wirkt.
Die passende Reaktion auf Fehler wählen
Make bietet Error-Handler mit unterschiedlichem Verhalten. Wichtig ist, sie bewusst auszuwählen, denn nicht jede Reaktion passt zu jedem Fehler:
- Vorübergehende Störung, etwa ein nicht erreichbarer Dienst: später erneut versuchen.
- Ungültige Daten, etwa eine fehlende Pflichtangabe: anhalten und an eine Person melden, denn eine Wiederholung ändert nichts.
- Unwichtiger Zusatzschritt, etwa ein interner Hinweis: Lauf fortsetzen, aber den Fehler festhalten.
- Mehrstufige Änderung, bei der ein Teilschritt fehlschlägt: prüfen, welche Änderungen rückgängig zu machen oder von Hand zu korrigieren sind.
Vorsicht gilt beim Ignorieren von Fehlern. Das Szenario sieht dann zwar erfolgreich aus, aber Daten fehlen möglicherweise. Nutzen Sie diese Option nur dort, wo ein Ausfall tatsächlich keine Folgen hat.
Änderungen sicher einspielen
Änderungen am laufenden Szenario sind eine häufige Fehlerquelle. Erstellen Sie vor größeren Anpassungen eine Kopie und testen Sie diese mit Testdaten oder eigenen Testverbindungen. Exportieren Sie außerdem wichtige Szenarien als Blueprint, damit Sie einen früheren Stand zur Hand haben. Notieren Sie in der Beschreibung, was geändert wurde und warum.
Sprachmodelle verdienen besondere Vorsicht. Geben Sie deren Ausgabe nicht ungeprüft an den nächsten Schritt weiter, sondern fordern Sie ein festes Format an und prüfen Sie Pflichtfelder und erlaubte Werte mit einem Filter. Liegt das Ergebnis außerhalb des Erwarteten, geht der Fall in eine Prüfliste. Funktionen und Bezeichnungen in Make können sich mit der Zeit ändern. Maßgeblich ist daher die aktuelle Dokumentation des Herstellers.
Wann Make passt und wann Sie weiterdenken sollten
| Situation | Einschätzung | Worauf es ankommt |
|---|---|---|
| Mehrere Cloud-Dienste mit vorhandenen Modulen verbinden | Gut geeignet | Klare Struktur, Rechte der Verbindungen und Fehlerpfade |
| Fachbereich soll einfache Abläufe selbst nachvollziehen können | Gut geeignet | Benennung, Dokumentation und klare Regeln für Änderungen |
| Sehr große Datenmengen in dichter Folge | Vorab genau prüfen | Laufzeit, Verbrauch und Grenzen der beteiligten Schnittstellen |
| Daten dürfen nur in der eigenen Infrastruktur verarbeitet werden | Oft andere Lösung nötig | Datenschutzvorgaben und Selbstbetrieb oder eigene Software |
| Umfangreiche Fachlogik mit vielen Sonderregeln | Eigene Software erwägen | Testbarkeit, Versionierung und langfristige Wartung |
Vor der Aktivierung eines Szenarios
Typische Fehler
So bleibt der Verlauf grün, obwohl Daten fehlen können. Unterscheiden Sie zwischen vorübergehenden und inhaltlichen Fehlern und melden Sie alles, was fachliche Folgen hat.
Schon eine kleine Änderung kann echte Kundendaten betreffen. Testen Sie Anpassungen in einer Kopie und sichern Sie vorher den aktuellen Stand.
Mit jedem Router und jeder Ausnahme wird der Ablauf schwerer zu verstehen. Lagern Sie getrennte Aufgaben aus und prüfen Sie bei viel Fachlogik, ob eigener Code besser passt.
Häufige Fragen
Wie viele Module sollte ein Make-Szenario haben?
Eine feste Grenze gibt es nicht. Wenn sich ein Szenario nicht mehr in wenigen Sätzen erklären lässt oder mehrere Verantwortlichkeiten mischt, sollten Sie es aufteilen.
Wie verhindere ich doppelte Datensätze in Make?
Nutzen Sie eine eindeutige Kennung aus dem Ursprungssystem und prüfen Sie vor dem Anlegen, ob der Datensatz schon vorhanden ist. Bereits verarbeitete Kennungen lassen sich auch in einem Data Store festhalten.
Wie teste ich Make-Szenarien, ohne echte Daten zu verändern?
Arbeiten Sie mit einer Kopie, Testkonten und Testdaten, soweit die angebundenen Systeme das ermöglichen. Bei schreibenden Schritten sollten Sie Testläufe im Zielsystem besonders aufmerksam kontrollieren.
Von Patrick Thomas, KI Sidekick. Dieser Artikel ersetzt keine Rechts- oder Steuerberatung.
