Diese Seite sammelt Fehlerquellen, die in größeren Workflow-Projekten wiederholt aufgetreten sind – unabhängig vom konkreten Anwendungsfall. Anders als Workflow-Vorfälle, die einen bereits eingetretenen Fehler melden, geht es hier um Muster, die sich beim Bau vermeiden lassen.
Verzweigungen & Schleifen
Ein Wartepunkt hört nach dem ersten Treffer auf zuzuhören. Führt die Rückschleife eines Gateways nur von einem Zweig zurück zum Wartepunkt – etwa nur vom „Ablehnen“-Pfad –, verlässt eine Instanz den Wartepunkt beim ersten passenden Zweig endgültig. Jede Rückschleife muss von allen Zweigen aus zum Wartepunkt zurückführen, die weiteres Warten bedeuten.
Ein sichtbarer Prüfschritt kann trotzdem nie ausgeführt werden. Ein Element existiert im Prozessmodell, ist aber an keinen Ausführungspfad angeschlossen – weder ein- noch ausgehend verbunden. Im Editor sieht es wie ein aktiver Teil des Ablaufs aus, läuft aber nie mit. Solche „toten Knoten“ entstehen häufig beim Umbau eines bestehenden Prozesses, wenn ein Element ersetzt statt entfernt wird.
Ohne Fallback wartet ein Workflow endlos. Kommt ein erwartetes Ereignis wiederholt nicht in auswertbarer Form an (z. B. ein Dokument ohne lesbaren Text), sollte nach einer definierten Anzahl erfolgloser Versuche eine Aufgabe für einen Menschen entstehen – statt dass der Workflow unbegrenzt weiterwartet.
Mehrere gleichzeitig eingehende Ereignisse führen zu doppelter Erkennung. Wertet ein Workflow jedes eingehende Dokument sofort einzeln aus, kann derselbe Sachverhalt (z. B. eine Frist) mehrfach erkannt und eingetragen werden, wenn mehrere Dokumente kurz hintereinander eintreffen. Eine kurze Sammelpause nach dem ersten Eingang – dann alle gemeinsam auswerten – behebt das gezielt.
Formulare & Aufgaben-Felder
Zwei parallele Aufgaben, ein Formular. Zielen zwei gleichzeitig aktive Aufgaben auf dieselbe Variable, überschreiben sie sich gegenseitig, sobald beide bearbeitet werden. Jede parallel mögliche Aufgabe braucht eine eigene Zielvariable, auch wenn die Formulare inhaltlich ähnlich sind.
Kombinierbare Felder sind nicht immer kombinierbar. Manche Task-Felder schließen sich gegenseitig aus, statt sich zu ergänzen – etwa ein Feld für den Titel eines einzelnen Eintrags und ein Feld, das pauschal „alle“ abschließt. Beide gleichzeitig gesetzt kann dazu führen, dass eine Aktion sich nicht auf den benannten Einzelfall, sondern auf sämtliche Einträge der Akte auswirkt. Bei Doppelfeldern mit ähnlicher Funktion vor dem Rollout genau prüfen, ob sie als Alternative oder als Kombination gedacht sind.
Tags & Bedingungen
Eine Tag-Bedingung kann auf mehr matchen als beabsichtigt. Prüft ein Workflow auf ein bestimmtes Dokumenten-Tag, um eine Aktion auszulösen, kann dieselbe Bedingung auch auf ein ähnlich benanntes, aber inhaltlich anderes Tag zutreffen (z. B. eine Vorlage statt der finalen Version). Tag-Namen und die darauf aufbauenden Bedingungen sollten eindeutig genug sein, um nicht versehentlich benachbarte Zustände zu erfassen.
Startregeln
Zwei Workflows mit identischer Aufgabe, aber nur eine Startregel gehört aktiviert. Existieren mehrere Workflows, die faktisch dasselbe leisten, und erhalten beide eine aktive Startregel für dasselbe Ereignis, lösen beide aus – mit doppelten Aktionen (z. B. doppeltem Versand) als Folge. Bei redundanten Workflows nur einen mit einer Startregel versehen und den anderen bewusst ohne belassen oder entfernen.
Qualitätssicherung
Jede Versandstelle einzeln gegen den Testmodus absichern. Ein Workflow kann mehrere Stellen enthalten, an denen eine Nachricht verschickt wird – Bestätigung, Erinnerung, Mahnung. Die Testmodus-Prüfung ist keine globale Einstellung, sondern muss an jeder einzelnen Versandstelle vorhanden sein. Eine vergessene Stelle reicht für einen echten Versand im Test.
Automatisch erkannte Werte immer bestätigen lassen. Auch wenn eine Erkennung (etwa eine KI-gestützte Fristextraktion) zuverlässig wirkt, sollte ihr Ergebnis vor der endgültigen Übernahme über eine Bestätigungsaufgabe laufen, statt direkt und ungesehen in die Akte geschrieben zu werden.
Textbausteine vor dem Rollout mit Testdaten prüfen. Alle Textbausteine einmal mit repräsentativen Testdaten füllen und als PDF ansehen, bevor sie live gehen. So fallen fehlerhafte FEEL-Ausdrücke (siehe Typische Stolperfallen) und fehlende Platzhalter-Fallbacks auf, bevor sie im Schreiben an Gericht oder Mandantschaft auftauchen.