Fehlerbehandlung und Wiederholungen in Zoho Flow richtig einrichten

Fehlerbehandlung und Wiederholungen in Zoho Flow richten Sie in drei Schritten ein. Sie lesen die Ablaufhistorie jedes kritischen Flows, bauen nach riskanten Aktionen einen Ausweichpfad mit Benachrichtigung und legen fest, welche Fehler ein Mensch prüft. Automatisch wiederholen sollten Sie nur Fehler, die vorübergehend sind.

Fehlerbehandlung in Zoho Flow ist die Gesamtheit der Vorkehrungen, die einen fehlgeschlagenen Lauf erkennbar machen, ihn melden und dafür sorgen, dass er nachgeholt wird. Ein Lauf ist eine einzelne Ausführung eines Flows. Ihn startet ein Auslöser (Trigger), etwa ein neuer Datensatz in Zoho CRM oder ein eingehender Webhook.

Ohne diese Vorkehrungen verschwinden Daten leise. Im Zoho-Forum berichten Nutzer von Flows, die nach Fehlern deaktiviert wurden. Ein anderer Nutzer schreibt, dass mindestens drei Flows plötzlich nicht mehr liefen. Diese Flows hatten zuvor sechs Monate bis mehrere Jahre fehlerfrei gearbeitet. Er nannte sie zentral für den Betrieb seines Unternehmens.

Besonders heikel sind Flows, die zwischen Zoho CRM, Zoho Books und Drittsystemen schreiben. Ein verlorener Lauf bedeutet dort einen fehlenden Kontakt, einen nicht aktualisierten Auftrag oder eine unvollständige Rechnung. Dieser Leitfaden zeigt, wie Sie solche Lücken sichtbar machen, bevor sie in der Buchhaltung auffallen.

Die meisten gemeldeten Fehler in Zoho Flow entstehen an der Grenze zwischen zwei Systemen, nicht im Flow selbst. Die folgenden Fehlerbilder stammen aus Beiträgen in der Zoho Community. Es sind Nutzerberichte, keine offiziellen Aussagen von Zoho.

Diese Fehlerbilder tauchen in den Berichten wiederholt auf:

• Auslöser startet im Livebetrieb nicht: Ein Flow auf neue Datensätze in einer Zoho-Creator-App lief im Modus „test and debug“, im Livebetrieb aber nicht. Ein zweiter Flow auf geänderte Deals in HubSpot startete ebenfalls nicht.
• Auslöser startet, der nächste Schritt nicht: Ein Flow nach Formulareinsendung wurde ausgelöst, lief aber nicht weiter. Er funktionierte zeitweise und fiel dann ohne Änderung wieder aus.
• Aktion liefert eine leere Ausgabe: „Get CRM Quote by ID“ zeigte die ID in der Fehlerhistorie, die Ausgabe war aber null.
• Datentyp passt nicht: Ein Kontrollkästchen in Zoho CRM lehnte den Wert ab, weil es einen Boolean erwartete. Ein Währungsfeld erwartete eine Zahl, Zoho Forms lieferte offenbar Text.
• Grenzwert überschritten: Viele parallele Läufe überschritten das Anfragelimit pro Minute von Zoho Analytics, der Flow wurde deaktiviert.
• Doppelte Auslösung: Ein Webhook kam zweimal innerhalb einer Sekunde an, beide Läufe scheiterten in Zoho Books.
• Fremdsystem meldet Fehler: Zoho Campaigns antwortete mit „Error in subscription. Please retry after sometime.“ und Fehlercode 2001.

Für jedes dieser Fehlerbilder brauchen Sie eine andere Antwort. Die folgenden Abschnitte ordnen sie zu.

Die Ablaufhistorie in Zoho Flow ist der Verlauf der einzelnen Läufe eines Flows. Sie zeigt je Schritt, welche Eingabe ankam und was zurückkam. Lesen Sie sie immer zuerst, bevor Sie einen Flow umbauen.

Gehen Sie bei einem fehlgeschlagenen Lauf in dieser Reihenfolge vor:

1. Bestimmen Sie den Schritt, an dem der Lauf abbrach.
2. Prüfen Sie, ob die Eingabe dieses Schritts vollständig war, etwa eine Datensatz-ID.
3. Lesen Sie die Ausgabe oder den Fehlertext wörtlich und notieren Sie einen Fehlercode.
4. Vergleichen Sie den Livelauf mit einem Lauf im Testmodus.
5. Notieren Sie Uhrzeit und Datum und prüfen Sie, ob der Fehler bei späteren Läufen wiederkehrt.

Der Vergleich zwischen Test und Livebetrieb ist entscheidend. Ein Nutzer berichtet, dass Zeit- und Datumsfunktionen im Flow plötzlich Fehler erzeugten. In der Testumgebung liefen dieselben Funktionen ohne Probleme. Ein erfolgreicher Test beweist also nicht, dass der Livebetrieb funktioniert.

Auch die Uhrzeit zählt. Im Bericht zum Formular-Flow funktionierte der Ablauf erst, fiel dann aus und lief eine Stunde später wieder, ohne dass jemand etwas geändert hatte. Ein solcher zeitweiliger Fehler verlangt eine andere Reaktion als ein Fehler, der bei jedem Lauf auftritt. Wer vorschnell umbaut, verschleiert die eigentliche Ursache.

Ein Ausweichpfad ist ein zweiter Zweig im Flow, der greift, wenn eine Aktion nicht das erwartete Ergebnis liefert. Statt still abzubrechen, meldet der Flow den Fall und markiert den betroffenen Datensatz. Bauen Sie ihn nach jeder Aktion, deren Ergebnis spätere Schritte brauchen.

Leere Ausgaben abfangen

Setzen Sie nach einer Leseaktion eine Entscheidung ein, die prüft, ob die Ausgabe Werte enthält. Der Fall „Get CRM Quote by ID“ mit Ausgabe null zeigt, warum. Ohne Prüfung schreibt der nächste Schritt leere Felder in Zoho Books oder bricht ab. Mit Prüfung leitet der Flow den Lauf in den Ausweichpfad.

Entscheidungen selbst testen

Prüfen Sie jede Entscheidung mit zwei Datensätzen: einem, der die Bedingung erfüllt, und einem, der sie nicht erfüllt. Ein Nutzer meldete Filter, die alles aussortierten, auch passende Datensätze. Ein falsch greifender Filter erzeugt keinen Fehler in der Historie. Der Lauf endet dann scheinbar erfolgreich, und die Daten fehlen trotzdem.

Datentypen vor dem Schreiben angleichen

Sorgen Sie dafür, dass jeder Wert im erwarteten Typ ankommt, bevor eine Aktion schreibt. Die gemeldeten Fehler bei Boolean-Feldern und Währungsfeldern entstanden genau an dieser Stelle. Verlassen Sie sich außerdem nicht ungeprüft auf Schleifen. Ein Nutzer berichtet, dass eine Schleife im Flow nicht tatsächlich wiederholt ausgeführt wurde.

Eine Wiederholung ist der erneute Versuch einer fehlgeschlagenen Aktion mit denselben Daten. Sie hilft nur, wenn der Fehler vorübergehend war. Bei einem dauerhaften Fehler liefert sie dasselbe Ergebnis noch einmal und verdeckt das Problem.

Vorübergehend sind Überlastungen und Grenzwerte. Ein Nutzer verwies auf status.zoho.com: Die durchschnittliche Antwortzeit stieg von 6 Millisekunden auf über 55 Millisekunden, dazu kamen Zeitüberschreitungen von über 30 Sekunden. Auch eine Meldung wie „Please retry after sometime“ deutet auf einen vorübergehenden Zustand hin.

Dauerhaft sind falsche Datentypen, fehlende Felder und falsch eingerichtete Verbindungen. Ein Nutzer meldete etwa, dass die Aktion „Update Invoice“ für Zoho Books kein Feld für den Änderungsgrund mehr bot. Solche Fehler löst kein zweiter Versuch.

Wiederholungen bremsen, nicht vervielfachen

Wiederholen Sie mit Abstand, zum Beispiel über eine Verzögerung (Delay) vor dem zweiten Versuch. Begrenzen Sie die Zahl der Versuche und übergeben Sie danach an einen Menschen. Der Fall mit Zoho Analytics zeigt das Risiko: Jeder markierte CRM-Datensatz startete einen eigenen Lauf. Die Anfragen überschritten das Limit pro Minute, und der Flow wurde deaktiviert.

Der Nutzer wünschte sich, Läufe einzeln mit Wartezeit dazwischen ausführen zu können. Bis dahin hilft nur, die Last bewusst zu verteilen, etwa indem Sie weniger Datensätze auf einmal markieren.

Doppelte Auslösung ist der Fall, dass ein Ereignis denselben Flow zweimal startet. Ein Webhook ist eine automatische Nachricht, die ein System bei einem Ereignis an eine Adresse schickt. Im Forumsbeitrag zu doppelt ausgelösten Webhooks schickte die Quelle gelegentlich zwei identische Webhooks innerhalb einer Sekunde.

Beide Läufe scheiterten an derselben Stelle, beim Aktualisieren eines Auftrags (Sales Order) in Zoho Books. Die Quelle ließ sich nicht ändern. Die Lösung musste also im Flow selbst liegen.

Schreibende Schritte idempotent machen

Idempotent heißt: Ein zweiter Lauf mit denselben Daten ändert nichts mehr. Lassen Sie den Flow vor dem Schreiben prüfen, ob der Vorgang schon verarbeitet wurde. Dafür eignet sich ein Markierungsfeld im Zieldatensatz, das der Flow nach erfolgreichem Schreiben setzt. Findet ein zweiter Lauf die Markierung, endet er ohne Aktion.

Auslöser eng fassen

Endlosschleifen entstehen, wenn ein Flow den Datensatz ändert, der ihn auslöst. Ein Nutzer wollte bei gewonnenem Deal einen Ordner mit Unterordner in Zoho WorkDrive und ein Projekt in Zoho Projects anlegen. Sein Flow lief mehrfach und wurde immer wieder deaktiviert. Grenzen Sie den Auslöser deshalb auf den Wechsel in die Phase „gewonnen“ ein. Kombinieren Sie das mit einem Markierungsfeld, das einen zweiten Durchlauf verhindert.

Eine Benachrichtigung ist der Teil der Fehlerbehandlung, der einen Menschen erreicht. Ohne sie bleibt ein deaktivierter Flow unbemerkt, bis Daten fehlen. In den Forumsberichten wurden Flows nach Fehlerserien deaktiviert, sowohl im Analytics-Fall als auch im Schleifen-Fall.

Planen Sie die Benachrichtigung so, dass der Empfänger ohne Rückfrage handeln kann. Sie sollte diese Angaben enthalten:

• den Namen des Flows und den gescheiterten Schritt
• die ID des betroffenen Datensatzes
• den Fehlertext wörtlich, einschließlich eines Fehlercodes
• den Zeitpunkt des Laufs

Eine unabhängige Kontrolle per Zeitplan

Ein Ausweichpfad im Flow hilft nicht, wenn der Flow gar nicht startet. Ergänzen Sie deshalb einen zeitgesteuerten Kontroll-Flow. Er prüft regelmäßig, ob neue Datensätze die erwarteten Markierungsfelder tragen. Im Bericht zu fehlschlagenden App-Auslösern lief ein zeitgesteuerter Flow weiterhin einwandfrei. Eine solche Kontrolle hängt nicht am Auslöser des überwachten Flows.

Bei Svennis legen wir für jeden Flow, der in Zoho Books schreibt, vor dem Livegang eine namentlich verantwortliche Person für Fehlermeldungen fest. Am häufigsten sehen wir bei Kunden einen Flow, der nach einer Fehlerserie deaktiviert wurde, ohne dass es jemand bemerkt hat.

Die Entscheidung zwischen automatischer Wiederholung und menschlicher Prüfung hängt vom Fehlerbild ab. Die folgende Tabelle ordnet die gemeldeten Fehlerbilder in Zoho Flow einer Behandlung zu.

Fehlerbild	Beispiel aus dem Forum	Automatisch wiederholen?	Wer prüft
Überlastung, Zeitüberschreitung	Antwortzeiten über 55 ms, Zeitüberschreitung über 30 s	Ja, mit Verzögerung und Obergrenze	Mensch erst nach letztem Versuch
Anfragelimit überschritten	Zoho Analytics, Flow deaktiviert	Nein, erst Last verteilen	Verantwortliche Person für den Flow
Fremdsystem meldet „retry“	Zoho Campaigns, Code 2001	Einmal, dann übergeben	Fachabteilung des Zielsystems
Datentyp falsch	Boolean-Feld, Währungsfeld	Nein	Person, die den Flow baut
Leere Ausgabe	„Get CRM Quote by ID“ liefert null	Nein	Fachabteilung mit Zugriff auf den Datensatz
Doppelte Auslösung	Sales Order in Zoho Books	Nein, Markierung prüfen	Buchhaltung bei jedem Treffer
Auslöser startet nicht	Creator- und HubSpot-Auslöser	Nicht möglich	Kontroll-Flow meldet an Verantwortliche

Eine Regel gilt unabhängig von der Tabelle. Jeder Fehler, der Aufträge oder Rechnungen in Zoho Books betrifft, geht an einen Menschen. Ein automatisch wiederholter Schreibvorgang in der Buchhaltung kann mehr Schaden anrichten als ein fehlender.

Das folgende Beispiel zeigt Fehlerbehandlung in Zoho Flow an einem Ablauf aus dem Zoho-Forum. Ein Nutzer verband Zoho Bookings, Zoho CRM und Zoho Campaigns. Sein Flow scheiterte im letzten Schritt.

Der ursprüngliche Flow bestand aus vier Schritten:

1. Auslöser: Eine neue Buchung wird in Zoho Bookings angelegt.
2. Ein Entscheidungsbaum wertet die Termindetails aus.
3. Der Flow holt die Kontaktdaten aus Zoho CRM.
4. Der Flow fügt den Kontakt einer Liste in Zoho Campaigns hinzu.

Schritt 4 scheiterte bei jedem Test mit „Error in subscription. Please retry after sometime.“ Der Nutzer fand nur den Hinweis auf Fehlercode 2001 in Zoho Campaigns. Er richtete die Verbindung neu ein, der Fehler blieb.

So sichern Sie denselben Ablauf ab

• Nach Schritt 3: Eine Entscheidung prüft, ob der CRM-Kontakt gefunden wurde. Fehlt er, meldet der Ausweichpfad die Buchung an das Vertriebsteam.
• Bei Schritt 4: Wenn Zoho Campaigns „retry“ meldet, folgt ein einziger zweiter Versuch nach einer Verzögerung.
• Nach Erfolg: Der Flow setzt im CRM-Kontakt ein Markierungsfeld „in Campaigns-Liste“.
• Kontroll-Flow: Ein zeitgesteuerter Flow sucht Kontakte mit Buchung, aber ohne Markierung, und meldet sie.

Der Fall zeigt, warum nach dem zweiten Versuch ein Mensch übernimmt. Das neue Einrichten der Verbindung half nicht. Weitere automatische Versuche hätten nur weitere Fehler erzeugt. Die zuständige Person trägt den Kontakt dann von Hand ein und klärt die Ursache in Zoho Campaigns.

Für Unternehmen im deutschsprachigen Raum endet ein verlorener Flow-Lauf häufig in der Buchhaltung. Viele geben ihre Daten aus Zoho Books an den Steuerberater weiter. Fehlt dort ein Auftrag oder eine Rechnung, ist auch die Übergabe an DATEV und den Steuerberater unvollständig.

Eine fehlende Rechnung fällt im Zweifel erst beim Bankabgleich in Zoho Books auf. Dann steht eine Zahlung ohne passenden Beleg im Konto. Bis dahin können Wochen vergehen, und die Ursache ist schwer zu rekonstruieren. Eine Benachrichtigung am Tag des Fehlers spart diese Suche.

Dasselbe gilt für Drittsysteme, die neben Zoho laufen. Wer etwa sevDesk an Zoho anbindet, hat zwei Datenbestände, die übereinstimmen müssen. Jede Integration zwischen ihnen braucht dieselben Bausteine: Prüfung der Ausgabe, Markierung nach Erfolg und eine unabhängige Kontrolle.

Planen Sie außerdem nicht damit, dass bei einem Fehler sofort Hilfe von außen verfügbar ist. Die erste Reaktion auf einen Flow-Fehler sollte deshalb aus Ihrem eigenen Team kommen.

Beginnen Sie mit den Flows, die in Zoho Books oder Zoho CRM schreiben, denn dort kostet ein verlorener Lauf am meisten. Arbeiten Sie die folgenden Schritte für jeden dieser Flows ab:

1. Listen Sie alle aktiven Flows auf und markieren Sie jene, die Aufträge, Rechnungen oder Kontakte schreiben.
2. Lesen Sie die Ablaufhistorie der letzten Läufe und notieren Sie jeden Fehlertext.
3. Prüfen Sie, ob ein Flow deaktiviert ist, ohne dass es jemand bemerkt hat.
4. Bauen Sie nach jeder Leseaktion eine Entscheidung ein, die leere Ausgaben abfängt.
5. Ergänzen Sie Markierungsfelder nach schreibenden Schritten und einen zeitgesteuerten Kontroll-Flow.
6. Ordnen Sie jedem Fehlerbild aus der Entscheidungstabelle eine verantwortliche Person zu.
7. Testen Sie jede Änderung mit einem echten Datensatz im Livebetrieb, nicht nur im Testmodus.

Für die meisten Unternehmen reicht diese Prüfung an einem Arbeitstag pro wichtigem Flow, um die größten Lücken zu sehen. Wenn Sie Zoho Flow neu einführen oder bestehende Integrationen neu ordnen wollen, finden Sie auf unserer Seite zur Einführung von Zoho Flow und App-Integration den Überblick, wie wir dabei vorgehen.

• Zoho Community: Zoho Flow to Campaigns, "Error in subscription. Please retry after sometime"
• Zoho Community: Zoho Flow triggers not working
• Zoho Community: My flow keeps going on loops and deactivated
• Zoho Community: Flow Delay and Filter Decisions Not Working
• Zoho Community: Action Iteration/Loop using Zoho Flow
• Zoho Community: How to Deal with Double-Fired Webhooks
• Zoho Community: timed execution
• Zoho Community: Zoho Flow, meistgemeldete Probleme
• Zoho Community: Flow triggers but doesn't continue