Flow & Workflow
Flow & Workflow ist die Engine für Prozessautomatisierung und Orchestrierung im Zentrum von Nashua 360. Sie verantwortet ein einziges, unvermeidliches Problem jedes Unternehmens: Arbeit bleibt nicht innerhalb eines einzigen Bildschirms. Ein eröffnetes Ticket muss weitergeleitet werden, eine eingehende Lieferantenrechnung muss genehmigt werden, ein auslaufender Vertrag muss eine Verlängerungsprüfung auslösen, und ein Datensatz, der seinen Zustand ändert, muss die Menschen und Systeme benachrichtigen, die von ihm abhängen. Überlässt man dies den einzelnen Modulen, zersplittert diese Koordination in fest verdrahtete Regeln, Nachfassen im Posteingang und undokumentierte Gepflogenheiten. Flow & Workflow ersetzt all das durch eine einzige deklarative Engine.
Das Modul stellt Fachverantwortlichen einen visuellen Designer bereit, um Prozesse als Flows aus Triggern, Bedingungen, Aktionen und Genehmigungen zu modellieren, gestützt auf einen suiteweiten Event-Bus, der jedes Lifecycle-Ereignis aus jedem Modul transportiert. Es ist als gemeinsam genutzte Infrastruktur in der Systemadministration angesiedelt, was bedeutet, dass jede Entität in Nashua 360, von einer Bestellung über eine Anlage bis hin zu einem Onboarding-Vorgang eines Mitarbeiters, einen Prozess starten, vorantreiben oder als Freigabestufe steuern kann, ohne eine einzige Zeile individuellen Codes. Es ist das verbindende Gewebe, das aus einer Sammlung starker Module ein koordiniertes Betriebssystem für das Unternehmen macht.
Was die Engine leistet
Flow & Workflow bietet ein vollständiges No-Code-Toolkit für die Prozessautomatisierung. Im Zentrum steht ein visueller Flow-Designer, in dem Prozesse als Graph aus Knoten gezeichnet werden, die durch Kanten verbunden sind: Ein Trigger startet den Flow, Bedingungsknoten leiten ihn weiter, Aktionsknoten erledigen die Arbeit, Genehmigungs- und Benachrichtigungsknoten binden Menschen ein, Verzögerungsknoten halten die Ausführung bis zu einem gewählten Zeitpunkt an, Webhook-Knoten erreichen externe Systeme, und ein Endknoten schließt den Durchlauf ab. Flows werden auf drei Arten ausgelöst: durch ein Ereignis an einem beliebigen Datensatz, nach einem wiederkehrenden Zeitplan oder bedarfsgesteuert durch eine Person oder einen AI Worker.
Aktionsknoten decken die Operationen ab, die ein Geschäftsprozess tatsächlich benötigt: das Versenden von E-Mails, das Anlegen oder Aktualisieren von Datensätzen in jedem Modul, den Aufruf eines registrierten Dienstes über die Plattform hinweg, das Senden an einen externen Endpunkt und das Auslösen von In-App-Benachrichtigungen. Bedingte Verzweigung lässt einen einzigen Flow jeden Pfad abbilden, den ein Vorgang nehmen kann, sodass ein Design die Ausnahmen aufnimmt, statt Varianten hervorzubringen. Ein integrierter Formular-Builder erfasst die Eingaben, die ein manueller Trigger oder eine Genehmigungsentscheidung erfordert, und SLA-Timer halten jede Stufe an ihre Frist und eskalieren automatisch, wenn ein Schritt zu lange dauert. Das Ergebnis: Ein Prozess, der einst nur im Kopf einer Person oder über eine Kette von E-Mails hinweg existierte, wird zu einem expliziten, versionierten, beobachtbaren Asset, das dem Unternehmen gehört und das es in Minuten ändern kann.
Die Domäne und das Datenmodell
Das konzeptionelle Modell ist klein, und zwar bewusst, und genau das macht es universell. Das zentrale Objekt ist der Flow: eine benannte, in sich geschlossene Beschreibung, wie ein Stück Arbeit ablaufen soll. Ein Flow wird als Graph ausgedrückt. Seine Schritte sind die einzelnen Verhaltensbausteine, jeder mit einem Typ und einer eigenen Konfiguration, und die Verbindungen zwischen ihnen tragen die Logik, die entscheidet, welcher Schritt auf welchen folgt, einschließlich der Bedingungen, die erfüllt sein müssen, damit ein bestimmter Pfad eingeschlagen wird. Weil die Gestalt eines Prozesses Daten sind und kein Code, lässt sich ein Flow untersuchen, kopieren, verfeinern und nachvollziehen, ohne die Plattform selbst zu berühren.
Jedes Mal, wenn ein Flow in Gang gesetzt wird, erzeugt die Engine einen Run: eine lebende Instanz mit eigenem Gedächtnis. Der Run hält fest, wo die Ausführung gerade steht, trägt den unterwegs gesammelten Kontext, die Eingabe, die ihn gestartet hat, und die Ausgabe, die jeder Schritt erzeugt, und führt seinen Status vom Moment des Beginns bis zum Abschluss, zur Pause oder zum Fehlschlag. Diese Trennung zwischen dem Design eines Prozesses und den einzelnen Durchläufen davon ist die zentrale Idee. Ein Flow kann Tausende von Runs gleichzeitig in Bewegung haben, jeden auf seinem eigenen Pfad, jeden nach einer Genehmigung oder einer geplanten Pause unabhängig fortsetzbar. Daneben steht der Genehmigungs-Workflow, eine wiederverwendbare Richtlinie, die für eine bestimmte Art von Datensatz und einen bestimmten Satz von Bedingungen festlegt, wer in welcher Reihenfolge zeichnen muss. Die Genehmigungsrichtlinie wird somit einmal definiert und konsistent angewendet, statt in jedem Flow, der eine Entscheidung braucht, neu spezifiziert zu werden.
Zentrale Workflows
Drei Muster decken das meiste ab, was Organisationen bauen. Das erste ist ereignisgesteuerte Automatisierung: Ein Autor entwirft einen Flow, wählt das Datensatzereignis, das ihn starten soll, etwa das Anlegen eines Vorgangs oder eine Statusänderung, und legt die darauf folgenden Aktionen und Verzweigungen fest. Von da an beobachtet die Engine den Event-Bus und löst in dem Augenblick, in dem das Ereignis eintritt, einen passenden Run aus, ohne dass ein Mensch beteiligt ist. Das zweite ist Genehmigungs-Routing: Ein Flow erreicht einen Genehmigungsknoten, die Engine erstellt eine Genehmigungsanfrage, pausiert den Run und benachrichtigt die zuständigen Genehmigenden. Mehrstufige, parallele und bedingt eskalierende Genehmigungen werden hier abgebildet, sodass eine Anfrage mit geringem Wert mit einer Unterschrift durchgeht, während eine mit hohem Wert mehrere Stufen durchläuft, alles aus demselben Design heraus.
Das dritte Muster ist geplante Verarbeitung: An einen Cron-Zeitplan gebundene Flows laufen zu festen Zeiten, um periodische Arbeit wie Erinnerungen, Verlängerungen, Abstimmungen und Aufräumtätigkeiten anzustoßen. Ein zentraler Scheduler prüft jede Minute die fälligen Flows, setzt alle Runs fort, deren Verzögerung abgelaufen ist, und schützt vor doppelter Ausführung innerhalb desselben Zeitfensters. Über alle drei hinweg wird jeder Run lückenlos nachverfolgt. Betreiber sehen, welche Flows aktiv sind, verfolgen einen Run Knoten für Knoten, lesen den Kontext, den er getragen hat, und verstehen genau, warum ein bestimmter Pfad eingeschlagen wurde und wo ein Fehler aufgetreten ist.
Funktionale Tiefe, die zählt
Die Präzision einer Prozess-Engine lebt in ihrer Routing-Logik, und genau hier ist Flow & Workflow kompromisslos. Der Bedingungsauswerter unterstützt einen reichhaltigen Satz von Operatoren, der Gleichheit und Ungleichheit, numerische Vergleiche, Zeichenkettentests wie Enthält, Beginnt-mit, Endet-mit und Musterabgleich, Mengenzugehörigkeit mit In und Nicht-in sowie Vorhandensein-Prüfungen abdeckt, ob ein Feld überhaupt existiert. Bedingungen lassen sich zusammensetzen: Jede Gruppe kann mit logischem Und, Oder und Nicht kombiniert werden, um beliebig fein abgestufte Regeln auszudrücken, und Werte werden per Dot-Path gelesen, sodass tief verschachtelte Felder des zu bewertenden Datensatzes direkt adressierbar sind. Kanten werden in einer definierten Reihenfolge nach der Regel First-Match-Wins ausgewertet, was jedes Mal deterministische, prüfbare Verzweigung ergibt.
Die Ausführung selbst ist auf Sicherheit und Vorhersehbarkeit ausgelegt. Jeder Run schreitet Schritt für Schritt voran, wobei sein Zustand bei jeder Bewegung persistiert wird, sodass ein Run eine Unterbrechung übersteht und sauber fortgesetzt wird. Eine begrenzte Schrittobergrenze verhindert außer Kontrolle geratene oder zyklische Flows. Webhook-Knoten, die über die Plattform hinausreichen, sind gegen Server-Side Request Forgery geschützt und an ein striktes Timeout gebunden, sodass eine externe Abhängigkeit einen Prozess nicht blockieren kann. Der Event-Bus-Katalog veröffentlicht jedes Ereignis, das die Plattform aussenden kann, mit Namen in Punktnotation und Wildcard-Abonnement, sodass ein Flow auf ein präzises Ereignis oder eine ganze Familie davon lauschen kann. Verzögerungs- und Genehmigungspausen sind vollwertige terminale Zustände, keine Behelfslösungen, und genau das erlaubt langlaufenden Prozessen mit menschlicher Beteiligung, über Tage zu laufen, ohne Ressourcen offen zu halten.
Wie es in die Nashua 360 Suite passt
Flow & Workflow ist die Automatisierungsschicht, auf der jedes andere Modul aufbaut, und es erwirbt diese Stellung durch tiefe, native Integration statt durch Konnektoren. Es greift direkt auf den Service-Bus der Plattform zu, sodass jeder Aktionsknoten eine von einem anderen Modul registrierte Fähigkeit aufrufen kann, ohne individuelle Verdrahtung. Es versendet über die gemeinsame Notification Engine, sodass die Nachrichten eines Flows die Nutzer in der App und per E-Mail über denselben Kanal erreichen, den auch der Rest der Suite nutzt. Es läuft gemeinsam mit der ETL-Pipeline auf dem zentralen Zeitplan, sodass geplante Flows und Datenbewegung auf einer Uhr koordiniert sind.
Weil der Event-Bus Lifecycle-Ereignisse aus der gesamten Suite transportiert, verdrahtet das Modul praktisch alles miteinander. Eine Änderung im CRM kann einen Vorgang im Service Management eröffnen. Eine genehmigte Anforderung im Procurement kann einen Datensatz im Finance anlegen. Eine auslaufende Vereinbarung im Contract Management kann eine Verlängerungsprüfung starten und den Kundenverantwortlichen benachrichtigen. Eine Neueinstellung im HR kann einen Onboarding-Flow auslösen, der Zugänge bereitstellt und Aufgaben plant. Identität und Berechtigungen werden durchgängig eingehalten, sodass ein Flow innerhalb derselben Zugriffsregeln handelt wie die Menschen, denen er dient. Flow & Workflow steht nicht neben der Suite: Es ist der Mechanismus, durch den sich die Suite wie ein einziges System verhält.
Wie AI Workers darin arbeiten
AI Workers sind vollwertige Teilnehmer in Flow & Workflow und werden von der Engine als eigenständige Nutzer behandelt. Über einen Dialog kann eine Person einen Worker bitten zu erklären, was ein Flow tut, warum ein bestimmter Run den eingeschlagenen Pfad genommen hat oder welche Prozesse einen gegebenen Datensatz berühren, und der Worker antwortet, indem er die modulinternen Flow- und Run-Daten abfragt. Workers handeln auch: Sie entwerfen und passen Flows aus natürlichsprachlicher Absicht heraus an, starten Runs, setzen pausierte fort und leiten Arbeit um, wenn sich die Umstände ändern, alles innerhalb der ihnen erteilten Berechtigungen.
Ihre Reichweite erstreckt sich über jeden Knotentyp. Ein AI Worker überwacht Runs auf Anomalien und Ausnahmen und macht eine stockende Genehmigung, einen verletzten SLA oder eine Häufung von Fehlern sichtbar, bevor daraus ein Problem wird. Wo ein Flow Informationen benötigt, die in einem Dokument oder einer unstrukturierten Nutzlast eingeschlossen sind, extrahiert und strukturiert ein Worker sie, sodass nachgelagerte Bedingungen mit sauberen Daten arbeiten können. Am bedeutsamsten: Ein Worker kann selbst als Genehmigungs- oder Prüfknoten dienen: Die Engine pausiert den Run, der Worker bewertet die Anfrage anhand von Richtlinie und Kontext, und er entscheidet entweder innerhalb seines Mandats oder eskaliert an eine Person, mit einer klaren Empfehlung und der beigefügten Begründung. Das verwandelt Flow & Workflow von reiner Automatisierung in echte Entscheidungsunterstützung, wobei menschliches Urteilsvermögen für die Fälle vorbehalten bleibt, die es wirklich brauchen.
