Automations: Workflows bauen & prüfen
Auslöser, Aktionen, Bedingungen, Variablen, Testläufe, Veröffentlichung und Knotenverlauf sicher beherrschen.
In diesem Kapitel11 Abschnitte
Automations führen wiederkehrende Abläufe aus, wenn ein Ereignis eintritt. Ein Workflow kann Datensätze prüfen, verzweigen, verändern und externe Dienste ansprechen. Weil er ohne weitere Rückfrage arbeitet, braucht er besonders klare Grenzen, Testdaten und Überwachung.
Für wen: Prozessverantwortliche, Builder und technische Administration
Stand: Dokumentationsstand siehe Stand-Zeile oben auf dieser Seite
Editionshinweis: Knoten, Codeausführung, Ausführungskontingente und Verlauf hängen von Plan und Betriebsform ab.
Aufbau verstehen
Eine Automation kann mehrere Workflows enthalten. Ein Workflow besteht aus Knoten:
- Trigger: startet den Ablauf, etwa bei Zeitplan, Datensatzereignis oder Webhook.
- Aktion: liest, erstellt oder verändert Daten und kann externe Dienste aufrufen.
- Router/Bedingung: wählt anhand eines Ausdrucks den passenden Pfad.
- Iterator: verarbeitet mehrere Ergebnisse schrittweise.
Ausgaben eines Knotens stehen nachfolgenden Knoten als Variablen zur Verfügung. Geben Sie
Workflows und Knoten fachliche Namen wie Neue Verkaufschance nachfassen statt Workflow 1.
Einen sicheren ersten Workflow bauen
Beispiel: Für eine neue Verkaufschance soll genau eine Aktivität Erstgespräch vereinbaren
entstehen. Ein Versand nach außen gehört nicht zu diesem Übungsablauf.
- Nutzen Sie getrennte Übungstabellen Verkaufschancen und Aktivitäten.
- Wählen Sie einen Trigger für eine neu angelegte Zeile in Verkaufschancen.
- Prüfen Sie, ob
Phase = Neuund eine Ansprechperson gesetzt ist. - Suchen Sie in Aktivitäten nach dem Verarbeitungsschlüssel dieser Chance, etwa
erstkontakt-plus Zeilen-ID. - Nur wenn keine solche Aktivität existiert: Legen Sie eine Aktivität mit Titel, Verknüpfung zur Chance und diesem Schlüssel an.
- Leiten Sie Zuständigkeit und Termin aus ausdrücklich gepflegten Eingabefeldern ab. Fehlende Werte gehören in eine Prüfansicht.
- Testen Sie Erfolg, fehlenden Kontakt und wiederholte Zustellung desselben Ereignisses.
- Veröffentlichen Sie erst nach erfolgreicher Prüfung.
Die Suche vor dem Anlegen verhindert einfache Wiederholungen, aber nicht automatisch zwei gleichzeitige Läufe. Für produktive Abläufe braucht es zusätzlich einen zuverlässig erzwungenen eindeutigen Schlüssel oder eine serialisierte Verarbeitung.
Entwurf, Test und Veröffentlichung
Ein neu gebauter oder geänderter Workflow bleibt zunächst im Entwurf. Testläufe verwenden Beispieldaten und zeigen Ausgaben je Knoten. Kontrollieren Sie dabei:
- stimmen Datentyp und Inhalt jeder Variablen,
- wird der richtige Zweig gewählt,
- verändert ein Test bereits echte Daten oder ruft ein echtes Fremdsystem auf,
- fehlen Werte oder Berechtigungen,
- ist der Ablauf bei Wiederholung weiterhin korrekt?
Achtung: Test bedeutet nicht automatisch „ohne Wirkung“. Verwenden Sie Testtabellen, Testempfänger und ungefährliche Endpunkte, solange Schreibaktionen beteiligt sind.
Nach der Veröffentlichung läuft der Live-Stand. Änderungen am Entwurf wirken erst nach einer erneuten Veröffentlichung. Halten Sie fest, wer freigegeben hat und welche Fälle geprüft wurden.
Idempotenz: doppelte Wirkung vermeiden
Trigger oder Netzwerkanfragen können wiederholt auftreten. Ein robuster Ablauf erkennt, ob
ein Vorgang bereits verarbeitet wurde. Möglich sind eine eindeutige Ereignis-ID, ein Feld
Verarbeitet am oder die Suche nach einem schon angelegten Zieldatensatz.
Ohne solche Kontrolle können doppelte E-Mails, Rechnungen oder Zeilen entstehen.
Fehler und Knotenverlauf
Seit Baserow 2.3 unterstützt der Automation Builder einen Verlauf auf Knotenebene. Prüfen Sie bei einem Fehler von vorn nach hinten:
- Hat der Trigger gültige Eingaben geliefert?
- Welcher Knoten schlug zuerst fehl?
- Waren Variable, Datentyp und Berechtigung korrekt?
- Antwortete ein externer Dienst mit Fehler oder Zeitüberschreitung?
- Entstand bereits eine teilweise Wirkung?
Speichern Sie keine Zugangsdaten in Klartextfeldern oder Protokollausgaben. Verwenden Sie die vorgesehene Geheimnis- oder Integrationsverwaltung Ihrer Umgebung.
Lauf stoppen und Wirkung prüfen
Baserow 2.4 bietet das Abbrechen eines laufenden Workflows. Der gerade ausgeführte Schritt kann noch fertiglaufen; bereits geschriebene Zeilen werden nicht zurückgesetzt. Prüfen Sie danach den Verlauf und vorhandene Aktivitäten, bevor Sie erneut starten.
Leistung und Kontingente
Cloud-Pläne können Automation-Credits oder Ausführungsgrenzen enthalten. Self-Hosted-Betrieb ist zusätzlich durch Arbeitsspeicher, Worker, Datenbank und angeschlossene Systeme begrenzt. Bei großen Mengen helfen Filter, Stapelverarbeitung und ein bewusstes Zeitfenster. Baserow 2.3 erweiterte die Stapelverarbeitung auf bis zu 1.000 Zeilen; testen Sie trotzdem mit Ihrer Instanz und dem verwendeten Knoten.
Veröffentlichungs-Check
Typische Fehler
Ein manueller Test kann echte Daten schreiben. Ein wiederholtes Ereignis darf keine zweite Aktivität erzeugen; ein abgebrochener Lauf setzt frühere Schritte nicht zurück.
