Workflows, Trigger & Aktionen

Ein Workflow beginnt bei genau einem Trigger-Schritt und verzweigt sich von dort aus auf einer visuellen Oberfläche – ziehen Sie Schritte an die gewünschte Stelle und zeichnen Sie eine Verbindung von einem zum nächsten. Jeder Schritt kann mit mehr als einem nächsten Schritt verbunden werden, und jeder Schritt kann Daten aus jedem vorherigen Schritt auf seinem eigenen Pfad verwenden.

Trigger-Schritte

Der Trigger ist immer Schritt null – er startet den Workflow. Jeder Trigger läuft in einem von drei Modi:

• Abfrage (Polling) — Gate97 prüft die verbundene App etwa alle 60 Sekunden auf Neues (eine neue Zeile, ein neues Issue, eine neue Bestellung). So funktionieren die meisten Trigger.
• Webhook — der Anbieter ruft Gate97 im Moment des Ereignisses auf. Derzeit funktioniert nur Stripes Zahlungsereignis-Trigger auf diese Weise; siehe Webhooks, wie man ihn einrichtet.
• Manuell — keine Abfrage, kein Webhook. Sie starten den Durchlauf selbst mit einem Klick im Dashboard, optional mit Einfügen einer Test-JSON-Nutzlast. Nützlich für Workflows, die Sie bei Bedarf statt automatisch auslösen möchten.

Ein Workflow läuft erst, sobald er aktiviert ist. Das Aktivieren eines Abfrage-Triggers startet dessen 60-Sekunden-Prüfungen; das Aktivieren eines Webhook-Triggers registriert eine eindeutige, nicht erratbare URL für diesen Schritt. Das Deaktivieren stoppt beides – nichts wird gelöscht, es hört nur auf auszulösen.

Jeder Abfrage- oder Webhook-Trigger kann auch im Stapelmodus laufen — Datensätze sammeln, statt für jeden einzeln einen Durchlauf auszulösen, und sie dann gemeinsam nach Zeitplan oder Bedingung übermitteln, mit eigenem Berichts-Dashboard. Siehe Stapelerfassung & Berichte.

Aktionsschritte

Jeder Aktionsschritt ruft einen Vorgang bei einer verbundenen App auf – eine Slack-Nachricht senden, einen Datensatz erstellen, ein Ticket aktualisieren usw. Ist ein Schritt mit mehr als einem nachfolgenden Schritt verbunden, laufen alle davon; schlägt er fehl, werden nur die Schritte auf seinem eigenen Pfad danach übersprungen – jeder andere, unabhängige Zweig läuft weiter.

Filterschritte

Ein Filterschritt prüft ein Feld gegen einen Wert und leitet den Durchlauf auf einen von zwei Pfaden: Verbinden Sie Schritte mit dem <b>Ja</b>-Ausgang für das, was passieren soll, wenn er übereinstimmt, und mit dem <b>Nein</b>-Ausgang für das, was passieren soll, wenn nicht. Lassen Sie eine Seite unverbunden, passiert auf diesem Pfad einfach nichts. Die verfügbaren Prüfungen sind equals, not_equals, contains, exists und not_exists. Zum Beispiel kann ein Filter, bei dem {{trigger.status}} gleich paid ist, aus demselben Ereignis eine Quittung über den Ja-Pfad und eine Fehlgeschlagen-Benachrichtigung über den Nein-Pfad senden.

Verzweigungen und mehrere Pfade

Verbinden Sie einen Schritt mit mehr als einem nächsten Schritt, und alle davon laufen – nützlich, um zum Beispiel aus demselben Ereignis unabhängig voneinander eine Slack-Nachricht zu senden und eine Tabelle zu aktualisieren. Die Ja- und Nein-Ausgänge eines Filterschritts funktionieren genauso, nur bedingt.

Ziehen Sie die +-Schaltfläche unter einem Schritt, um einen neuen, bereits verbundenen Schritt hinzuzufügen; ziehen Sie einen bestehenden Schritt, um ihn an eine andere Stelle auf der Oberfläche zu verschieben; wählen Sie eine Verbindung aus und löschen Sie sie, um zwei Schritte zu trennen.

Daten zwischen Schritten zuordnen

Jedes Textfeld in der Konfiguration eines Schritts kann die Ausgabe eines früheren Schritts mit der {{ }}-Template-Syntax referenzieren:

• {{trigger.fieldName}} — ein Feld aus der Ausgabe des Trigger-Schritts.
• {{step1.fieldName}}, {{step2.fieldName}} usw. — ein Feld aus der Ausgabe des Schritts, den Sie als N-ten hinzugefügt haben. Diese Nummerierung wird einmalig bei der Erstellung des Schritts festgelegt und ändert sich nie, unabhängig davon, wo er sich auf der Oberfläche befindet oder wie er verbunden ist.

Welche Felder genau verfügbar sind, hängt davon ab, was der Connector des vorherigen Schritts zurückgibt — nutzen Sie zuerst Diesen Schritt testen am vorherigen Schritt, um dessen tatsächliche Ausgabestruktur zu sehen, bevor Sie später im Workflow darauf verweisen.

Einen Schritt testen

Jeder Schritt hat eine Schaltfläche Diesen Schritt testen. Sie führt genau diesen Schritt jetzt real gegen die verbundene App aus (oder, bei einem Trigger-Schritt, gegen eine von Ihnen bereitgestellte JSON-Nutzlast) und zeigt die echte Antwort oder den Fehler — derselbe Codepfad, den ein echter Durchlauf nutzt, sodass das, was Sie hier sehen, tatsächlich passieren wird, sobald der Workflow aktiv ist.

Ausführungsverlauf

Jedes Mal, wenn ein Trigger auslöst, wird ein Durchlauf erstellt und erscheint im Ausführungsverlauf dieses Workflows — ob erfolgreich, fehlgeschlagen oder von einem Filter gestoppt, zusammen mit der echten Eingabe und Ausgabe jedes Schritts. Dies ist der erste Ort, an dem Sie nachsehen sollten, wenn ein Workflow nicht das tut, was Sie erwarten.