Automations: Workflows bauen & prüfen
Auslöser, Aktionen, Bedingungen, Variablen, Testläufe, Veröffentlichung und Knotenverlauf sicher beherrschen.
In diesem Kapitel8 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: Baserow 2.3.2, Juli 2026
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 Fällige Aufträge täglich prüfen statt Workflow 1.
Einen sicheren ersten Workflow bauen
Beispiel: Neue Serviceaufträge mit hoher Priorität sollen markiert und einer Person zugewiesen werden.
- Erstellen Sie einen Trigger für neu angelegte Zeilen.
- Lesen Sie nur die benötigten Eingaben des Triggers.
- Prüfen Sie in einer Bedingung, ob
Priorität = Hochgilt. - Aktualisieren Sie Status oder Zuständigkeit.
- Protokollieren Sie Ergebnis und fachlich nötige Referenz.
- Testen Sie hohe, normale und fehlende Priorität.
- Veröffentlichen Sie erst nach erfolgreicher Prüfung.
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.
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.