Automatisierung, Workflows und Reporting

Nutzen Sie Automatisierung, um Workflows, Workflow-Instanzen, Wiederholungsrichtlinien, Monitoring und Taskstream-Jobs zu verwalten. Reporting-Seiten zeigen verdichtete Auswertungen für fachliche Bereiche.

Diese Seite passt, wenn Sie Freigabeprozesse, Workflow-Automatisierung, Folgeprozesse oder operative Auswertungen in Workspace administrieren. Nach dem Lesen wissen Sie, welche Setup-Prüfungen vor fachlicher Nutzung nötig sind und wo Sie laufende Instanzen, Wiederholungen, Monitoring und blockierte Jobs prüfen.

Ablauf im Überblick

System Setup, Betriebsbereitschaft und Tenant Init prüfen

Prüfen Sie vor der fachlichen Workflow-Nutzung, ob die globale System-Initialisierung abgeschlossen ist, die Betriebsbereitschaft keine blockierenden Hinweise zeigt und die Mandanteninitialisierung für den Zielmandanten abgeschlossen ist.

System Setup plant und aktiviert die kanonische Workflow-Library und weitere globale Artefakte als nachvollziehbare Releases. Prüfen Sie Zielrelease, Blocker und Apply-Lauf wie unter Systemartefakt-Releases sicher anwenden beschrieben. System > Betrieb > Betriebsbereitschaft zeigt danach, ob systemweite Verträge und Verbindungen bereit sind oder noch blockieren. Tenant Init legt anschließend tenant-lokale Runtime-Daten, Konfigurationen, Gruppen, Jobs und optionale Presets an. Tenant Init kopiert die Standard-Workflows nicht in jeden Mandanten; tenant-lokale Konfigurationen verweisen auf die systemseitigen Workflow-Keys.

Für neue oder zurückgesetzte Mandanten gilt:

Öffnen Sie System > Konfiguration > Setup und prüfen Sie die Systemartefakte, die Ihre ausgewählten Module benötigen. Für das Rezept Workflow-Runtime testen müssen mindestens Workflow-Library und System-Tenant-Vorlagen bereit sein, weil das Rezept neben workflow-nahen Modulen auch Verträge initialisiert. Planen und wenden Sie fehlende Artefakte wie unter Systemartefakt-Releases sicher anwenden beschrieben an.
Öffnen Sie System > Betrieb > Betriebsbereitschaft und prüfen Sie, ob relevante systemweite Checks ok sind oder fachlich erklärbare Hinweise zeigen.
Öffnen Sie System > Mandanten, wählen Sie den Mandanten und wechseln Sie in den Tab Initialisierung.
Wählen Sie ein passendes Rezept oder die benötigten Module. Für Commerce- und Storefront-Arbeit brauchen Sie mindestens Lokalisierung, Commerce und PIM; für workflow-nahe Runtime-Daten wählen Sie zusätzlich Workflows.
Führen Sie zuerst die Simulation aus. Prüfen Sie geplante, übersprungene und warnende Einträge.
Starten Sie die Initialisierung erst nach fachlicher Prüfung des Plans.

Wenn Workflows, Lifecycle-Aktionen, PIM-Readiness oder Commerce-Grundlagen fehlen, reparieren Sie das nicht durch direkte Feldänderungen. Prüfen Sie zuerst System Setup, Betriebsbereitschaft, Tenant Init und die Diagnosewege in Diagnose und Readiness.

Workflows pflegen

Öffnen Sie Automatisierung > Workflows > Workflows.

Ein Workflow beschreibt einen fachlichen Ablauf mit Entitätstyp, initialem Status, Aktivkennzeichen, Quelle und optionalem Arbeitsbereich. Die Detailansicht trennt den Designer als eigenen Arbeitsbereich ab. Im Detailformular wechseln Sie unterhalb von „Speichern“ zwischen den Tabs Allgemein und Übersetzungen.

Aktivieren Sie nur Workflows, die fachlich geprüft sind. Deaktivieren Sie alte Varianten statt sie unkontrolliert parallel zu verwenden.

Interne Actions rufen serverseitige Fachlogik auf und benötigen deshalb neben dem normalen Create- oder Update-Recht den Scope workflow_actions:internal_manage. Das Preset staff-admin enthält diesen Scope. Weisen Sie ihn eigenen Rollen nur dann ausdrücklich zu, wenn diese Rollen interne Actions anlegen oder bei einem Update beibehalten dürfen. Der Scope macht keine system_only-Action für tenant-eigene Definitionen verfügbar. Das Löschen einer internen Action und die Umstellung auf einen nicht internen Action-Typ benötigen den Zusatzscope nicht.

Automatische Trigger kontrolliert in Betrieb nehmen

Event-, Zeit- und Bedingungs-Trigger erzeugen Transitionen ausschließlich über persistierte, tenantgebundene Requests. Die Runtime bleibt nach Installation global deaktiviert. Bestehende Trigger besitzen zunächst keine Aktivierungsgeneration und führen deshalb nichts aus.

Der Reconcile bindet jede Aktivierung an den Business-Tenant und löst dort zuerst einen Tenant-Override, danach einen passenden System-Fallback auf. Systemdefinitionen erzeugen keine System-Tenant-Ausführung. Die Runtime prüft den globalen Kill-Switch erneut vor Scanner, Scheduler, Delivery-Claim und Transition-Request. Wird er deaktiviert, startet sie keine neue fachliche Ausführung. Bereits persistierte interne Materialisierungs- und Delivery-Events bleiben ohne zusätzlichen Fehlversuch eingereiht und werden frühestens nach 15 Sekunden erneut geprüft. Nach der erneuten Aktivierung läuft die Verarbeitung weiter; abgelaufene fachliche Claims können gefencet übernommen werden.

Gehen Sie für die Aktivierung in dieser Reihenfolge vor:

Prüfen Sie den Trigger fachlich und stellen Sie sicher, dass er nur eine automatische Transition adressiert.
Führen Sie den tenantgebundenen Dry-Run aus:

console

   nucli workflow triggers reconcile <trigger-id>

Beheben Sie gemeldete Verstöße. Aktivieren Sie den Trigger erst nach einem erfolgreichen Dry-Run:

console

   nucli workflow triggers reconcile <trigger-id> --apply

Aktivieren Sie die globale Konfiguration workflow.trigger_runtime.enabled erst, wenn alle vorgesehenen Trigger geprüft und die Runtime-Metriken in das Betriebsmonitoring aufgenommen wurden.

Die erste Katalogversion erlaubt neue und aktualisierte Scheduling-Buchungen. Weitere angezeigte Fact-Typen bleiben gesperrt, bis ihr Producer-Vertrag gehärtet ist. Event-Payloads sind auf 32 KiB und höchstens vier Subjects begrenzt. Pro Workflow und Fact sind höchstens acht nicht überlappende Trigger zulässig. Zeit- und Bedingungs-Trigger verwenden fünfstellige UTC-Cron-Ausdrücke mit mindestens einer Minute Abstand.

Ein historischer Replay entsteht nie implizit. Prüfen Sie zuerst einen tenant-, Topic- und Zeitfenster-gebundenen Lauf:

console

nucli workflow triggers replay \
  --topic scheduling.booking.created \
  --from 2026-07-23T08:00:00Z \
  --to 2026-07-23T09:00:00Z

Erzeugen Sie die Replay-Generation nur nach Prüfung der Trefferzahl mit demselben Befehl und --apply. Verwenden Sie keine direkte Datenbankänderung. Correlation, Causation, Trigger-Tiefe und bereits besuchte Trigger werden bei automatischen Folgeübergängen weitergegeben. Workspace beendet einen Pfad fail-closed, sobald er einen Trigger erneut betritt oder die maximale Tiefe überschreitet.

Layout eines System-Workflows anpassen

Die Quelle in der Workflow-Detailansicht zeigt, ob Sie einen zentral bereitgestellten System-Workflow oder einen eigenen Workflow geöffnet haben. Bei einem System-Workflow bleibt die fachliche Definition im Mandanten geschützt: Sie können weder Zustände und Übergänge noch Regeln, Trigger oder Aktionen ändern. Sie können jedoch die Anordnung des Diagramms an Ihre Arbeitssicht anpassen.

Öffnen Sie den System-Workflow und wechseln Sie in den Tab Designer.
Verschieben Sie Zustände mit der Maus oder wählen Sie Automatisch anordnen.
Prüfen Sie die Erfolgsmeldung an der ausgelösten Aktion.
Laden Sie die Seite erneut und kontrollieren Sie die gespeicherte Anordnung.

Workspace speichert diese Layoutsicht nur für den aktuellen Mandanten und die geöffnete Workflow-Version. Andere Mandanten sehen ihre eigene Anordnung oder weiterhin das zentrale Standardlayout. Die Anpassung kopiert den System-Workflow nicht und trennt den Mandanten nicht von späteren zentralen Workflow-Releases.

Wenn Sie die fachliche Definition ändern müssen, erstellen Sie dafür bewusst einen tenant-eigenen Workflow-Override. Eine reine Layoutänderung ist kein Definition-Override.

Workflow-Arbeitsbereiche nutzen

Öffnen Sie Automatisierung > Workflows > Workflow-Arbeitsbereiche, wenn Workflows nach Arbeitsbereichen strukturiert werden sollen.

Arbeitsbereiche helfen, fachliche Abläufe getrennt zu organisieren und Auswertungen gezielter zu filtern.

Workflow-Instanzen prüfen

Öffnen Sie Automatisierung > Workflows > Workflow-Instanzen, um laufende oder abgeschlossene Instanzen zu prüfen.

Nutzen Sie diese Sicht bei Support- und Prozessfragen: Sie sehen, welcher Workflow betroffen ist und in welchem Status eine Instanz steht.

Wiederholungsrichtlinien pflegen

Öffnen Sie Automatisierung > Workflows > Wiederholungsrichtlinien.

Eine Wiederholungsrichtlinie steuert unter anderem maximale Versuche und den Übergang in Dead-Letter-Zustände. Setzen Sie Richtlinien so, dass vorübergehende Fehler erneut versucht werden, dauerhafte Fehler aber sichtbar bleiben.

Workflow Monitoring nutzen

Öffnen Sie Automatisierung > Workflows > Workflow Monitoring.

Das Monitoring zeigt:

gesamte Instanzen
aktive Instanzen
Dead Letters
Erfolgsrate
neue Instanzen im Zeitverlauf
Statusverteilung nach Workflow

Nutzen Sie Filter, um bestimmte Zeiträume, Workflows oder Arbeitsbereiche zu prüfen.

Wenn ein Dead-Letter-Eintrag gezielt erneut ausgeführt werden soll, verwenden Sie den Tab Wiederherstellung. Dort prüfen Sie den betroffenen Schritt, beheben zuerst die Ursache und planen anschließend ausschließlich eine sichere Wiederholung ein. Der tenantgebundene UI- und nucli-Ablauf ist unter Workflow-Wiederherstellung beschrieben. Führen Sie keine direkte Datenbankänderung durch.

Taskstream-Jobs prüfen

Öffnen Sie Automatisierung > Taskstream > Jobs, um Hintergrundjobs zu prüfen.

Taskstream verarbeitet asynchrone Aufgaben wie Scans, Derivate, Erinnerungen oder periodische Prüfungen. Prüfen Sie Jobs, wenn erwartete Aktionen verzögert sind.

Taskstream läuft aktuell im eingeschränkten Sicherheitsbetrieb. Für neue oder geänderte Jobs stehen die Scheduler cron, interval, delay, instant und time bereit. event kann zusätzlich erscheinen, wenn der Server für den aktuellen Mandanten das Feature taskstream.scheduler.event, dessen aktuelle Revision und den persistenten Watch-Vertrag der Runtime bestätigt. Das Feature bleibt standardmäßig deaktiviert. inotify bleibt für neue oder geänderte Jobs gesperrt. Historische Jobs mit nicht angebotenen Schedulern oder Runnables bleiben lesbar, lassen sich aber nicht erneut mit demselben Altvertrag speichern.

Die Job-Oberfläche übernimmt auswählbare Typen und Vorgabewerte aus der aktuellen Serverantwort. Ist die Antwort leer, unbrauchbar oder nicht erreichbar, zeigt Workspace nur die sichere Grundmenge und schaltet keine riskanten Typen lokal frei. Ein historischer, aktuell nicht angebotener Typ bleibt mit seinen gespeicherten Werten sichtbar; seine Konfigurationsfelder sowie Fortsetzen und Ausführen bleiben deaktiviert. Wählen und speichern Sie nach Ihrer fachlichen Prüfung bewusst einen aktuell angebotenen Scheduler und Runnable, wenn Sie den Job konvertieren möchten. Für Inotify setzt die Oberfläche keinen Pfad voraus und insbesondere keinen absoluten /tmp-Pfad.

Der Runnable event erscheint nur, wenn der Server das Tenant-Feature taskstream.runnable.event mit einer aktuellen Revision bestätigt. Verwenden Sie ein kleingeschriebenes logisches Topic mit höchstens 128 Zeichen; zulässig sind Buchstaben von a bis z, Ziffern, Punkt, Unterstrich und Bindestrich. Das Topic muss mit einem Buchstaben oder einer Ziffer beginnen. Die optionale Payload besteht ausschließlich aus JSON-Daten und darf serialisiert 64 KiB nicht überschreiten. Workspace bindet das Event intern an den aktuellen Tenant. Sie können damit weder allgemeine Domain-Topics noch Metadaten, Credentials oder Authority-Werte setzen. Der Publish erfolgt prozesslokal und ist keine persistierte oder clusterweite Zustellungszusage.

Wählen Sie den Scheduler event nur, wenn er in der aktuellen Capability-Antwort angeboten wird. Tragen Sie auch dort ausschließlich ein logisches Topic nach demselben begrenzten Format ein. Der Scheduler bindet die Subscription an den aktuellen Mandanten und Job. Pro Job hält genau ein Cluster-Owner eine befristete Watch-Lease; ein monotoner Fence sperrt alte Owner. Mehrfache Zustellung derselben nicht leeren Envelope-ID erzeugt für dieselbe Jobgeneration und dasselbe Topic keine zweite Occurrence.

Der Server begrenzt reaktive Watches auf 32 je Mandant und 256 je Node. Bei Feature- oder Revisionsentzug, verlorener Lease, Pause, Archivierung, Stop oder Shutdown entfernt er die Subscription spätestens innerhalb von zwei Sekunden. Der Bus bleibt trotzdem prozesslokal: Publisher und Scheduler müssen denselben Engine-Prozess erreichen. Die Watch-Lease verhindert doppelte Owner im Cluster, ersetzt aber keinen clusterweiten Eventtransport.

Eine geänderte Runnable- oder Scheduler-Feature-Revision macht einen bestehenden Job prüfpflichtig. Ausführen und Wiederherstellen erneuern die Bindung nicht. Prüfen Sie den vollständigen Job und speichern Sie ihn mit PUT oder setzen Sie ihn über Fortsetzen gezielt mit einer neuen autorisierten Generation fort. Nehmen Sie keine direkte Datenbankänderung vor.

Ein separat bereitgestellter Rootless-OCI-Runner ändert diese Typenliste nicht. Er ist nur die isolierte technische Voraussetzung für spätere Shell- und Lua- Verträge. Positive Runner-Readiness aktiviert kein Feature und entsperrt keinen historischen Job. Hinweise für Betreiber stehen unter Taskstream-Runner sicher vorbereiten.

Die öffentliche/API/UI-Ausschlussmenge für neue oder geänderte Jobs kombiniert das Worker-Emergency-Runnable-Deny shell, http, lua mit den neun systemtenantgebundenen internen Typen exchange-rate-sync, staff_time.holidays.sync.ensure, staff_time.retention.cleanup.ensure, staff.alerts.overtime_check.ensure, storage.retention.cleanup.ensure, hr-vacation-reconcile.ensure, media.cache.cleanup.ensure, accounting.drift.check.ensure und staff.absence.open_request_reminders.ensure. Planen Sie dafür keinen Aktivierungs- oder Freischaltpfad ein. Wenn Sie einen historischen Job weiterverwenden müssen, konvertieren Sie ihn bewusst komplett auf einen fachlich und operativ freigegebenen, nicht enthaltenen Typ.

Der Typ workflow kann sichtbar bleiben. Verlassen Sie sich darauf aktuell nicht als Taskstream-Ausführungspfad: Der Server verdrahtet derzeit keine Workflow-Engine in Taskstream, und transitive Workflow-Actions wie event, webhook oder lua sind keine Sicherheitsgarantie im aktuellen eingeschränkten Sicherheitsbetrieb.

Nutzen Sie Taskstream-Reads, Logs und Health-Sichten nur im vertrauenswürdigen Operator-Kontext. Workspace begrenzt neue öffentliche Logs, entfernt Credential- und Infrastrukturdetails und bewahrt technische Ausführungsnachweise nach festen Fristen auf. Ein Legal Hold schützt die Nachweise eines Jobs vor Reset und Löschung. Die genauen Fristen, Prüfungen und API-Aktionen beschreibt Taskstream-Historie und Aufbewahrung. Offene Timeout- und Fairness-Themen begrenzen Taskstream weiterhin auf kontrollierte Workloads. Im Standardmodus sperrt das Edge alle extern erreichbaren mutierenden /api/v1/jobs-Routen.

Die Job-Hygiene oberhalb der Liste zeigt aktive, archivierte und prüfpflichtige Jobs. Nutzen Sie Archiv prüfen, bevor Sie viele Jobs aus der aktiven Sicht nehmen. Workspace lädt dafür eine serverseitige Vorschau und markiert nur geeignete Kandidaten als archivierbar.

Archivieren Sie vor allem abgeschlossene Einmaljobs, zum Beispiel einmalige Imports, manuell gestartete Derivate oder beendete Setup-Läufe. Archivierte Jobs verschwinden aus der aktiven Liste, bleiben aber mit Logs und Statistiken erhalten. Workspace führt archivierte Jobs nicht automatisch oder manuell aus. Mit Archiv anzeigen laden Sie archivierte Jobs in der Hygiene-Fläche und können einzelne Jobs wiederherstellen.

Prüfen Sie diese Fälle fachlich, bevor Sie handeln:

fehlgeschlagene oder abgebrochene Einmaljobs
pausierte wiederkehrende Jobs
Jobs mit Event-, Inotify-, Cron- oder Intervall-Scheduler
Jobs, die noch pending, queued, running oder retrying sind

Löschen Sie Jobs nur, wenn kein Hold, keine laufende Ausführung und kein referenzierter Autorisierungsnachweis mehr besteht. Für normale Aufräumarbeiten ist Archivieren die sichere Option.

Manuelle Fulfillment-Folgeprozesse steuern

Physische Varianten können im PIM eine Erfüllungsstrategie tragen. Lagerware läuft über Reservierung und Versand. Strategien wie finish_to_order, assemble_to_order, make_to_order und procure_to_order markieren einen Folgeprozess. Die fachliche Auswahl der Strategien ist in Fulfillment-Strategien wählen beschrieben.

Prüfen Sie organisatorisch, wer diese Folgeprozesse bearbeitet:

Fertigung oder Werkstatt für finish_to_order, assemble_to_order und make_to_order
Einkauf oder Disposition für procure_to_order
Handel oder Operations für Auftragskontrolle und Kundenkommunikation
Lagerverwaltung erst dann, wenn fertige Ware tatsächlich gebucht, gepickt oder versendet wird

Der Modus manual bleibt Standard. Dann legen Anwender den Folgeprozess in der Bestellung über die serverseitig angebotene Aktion an. Setzen Sie fulfillmentFollowUpMode nur dann auf automatic, wenn Manufacturing-Plan oder Lieferantenkontext eindeutig gepflegt sind und die verantwortlichen Teams blockierte Folgeprozesse prüfen.

Der automatische Pfad nutzt denselben Command wie der Button. Er bucht keine fertige Ware ohne Wareneingang oder Produktionsabschluss und ersetzt keine fachliche Prüfung. Reporting sollte deshalb offene Follow-ups, blockierte Fertigungspläne, fehlende Lieferantenkontexte und verspätete Folgeprozesse sichtbar machen, statt still Bestand oder Bestellungen zu korrigieren.

Tracking-Governance für Seriennummern und Chargen

Seriennummern und Chargen verbinden Stammdaten, Wareneingang, Bestand, Picking, Versand und Retoure. Legen Sie organisatorisch fest, wer Tracking-Typen pflegt und wer operative Nummern erfasst.

Prüfen Sie vor dem Produktivbetrieb:

Produktteams dürfen Tracking-Typ und Seriennummernquelle im Logistikbereich physischer Varianten pflegen. Die Seriennummernquelle ist nur bei Seriennummerntracking relevant.
Lagerteams dürfen Wareneingang, Picking, Versand und Tracking-Pool bedienen.
Varianten mit der Seriennummernquelle Interne Fertigung dürfen nicht über Lieferanten- oder Papierwareneingänge eingebucht werden. Prüfen Sie Produktstammdaten und Beschaffungsweg gemeinsam, bevor Sie eine seriennummerngeführte Variante produktiv nutzen.
Support- oder Lagerleitungen dürfen Tracking-Korrekturen nur mit nachvollziehbarem Grund ausführen.
Lager, Lagerfächer und Quarantäneprozesse sind vorbereitet, bevor trackingpflichtige Ware eingeht.

Nutzen Sie Workflows, Aufgaben oder Reporting, um fehlende Nummern, blockierte Picks oder gesperrte Chargen sichtbar zu machen. Automatisieren Sie keine Korrektur, die Bestand, Seriennummern oder Chargen ohne fachliche Prüfung verändert.

Reporting verwenden

Workspace bietet bereichsspezifische Reporting-Seiten. Belegte Beispiele sind:

CRM > Berichte > Vertriebsanalyse
Handel > Berichte > Versandgesundheit
Handel > Berichte > Versandalarme
Automatisierungsstatistiken mit Durchsatz, Recovery, offenen Jobs und Fehlerlisten

Nutzen Sie Reporting für operative Steuerung. Prüfen Sie bei Entscheidungen immer Zeitraum, Filter und Berechtigungskontext.

Grenzen

Monitoring und Reporting zeigen Zustände aus den vorhandenen Arbeitsbereichsdaten. Sie ersetzen keine fachliche Ursachenanalyse und keine externe Auditierung.