Wer in der JTL-Wawi wiederkehrende Schritte manuell erledigt, verliert Zeit und erzeugt Fehlerquellen. Genau hier setzen JTL Workflows an: Sie reagieren auf Ereignisse, prüfen Bedingungen und führen Aktionen aus – vom Statuswechsel bis zum Druckauftrag.
Dieser Beitrag ist die zentrale Einstiegsseite zu Automatisierung mit JTL-Wawi-Workflows. Er erklärt Aufbau, Möglichkeiten und Grenzen und zeigt anonymisierte Praxisbeispiele aus realen Umsetzungen. Vertiefende Anleitungen bleiben in den JTL-Workflows im T4DT Helpdesk.
Ziel ist eine fachlich belastbare Orientierung: Wann reichen Standardaktionen, wann helfen PowerShell, CustomWorkflows oder eigene Tools – und wann lohnt individuelle Entwicklung.
JTL-Workflows sind Regelwerke in der JTL-Wawi. Sie verbinden ein Ereignis mit Bedingungen und Aktionen. So lassen sich JTL-Prozesse automatisieren, ohne jeden Vorgang manuell anzufassen.
Typische Objekte sind Auftrag, Artikel, Lieferschein oder Rechnung. Manuelle Workflows lassen sich gezielt starten; zeitgesteuerte und ereignisbasierte Läufe übernehmen den Hintergrundbetrieb.
Wichtig: Ein Workflow ersetzt keine Prozessklarheit. Erst wenn Auslöser, Zustände und gewünschtes Ergebnis klar sind, bleibt die Automatisierung wartbar – besonders bei JTL-Wawi-Workflows mit vielen Verzweigungen.
Jeder belastbare JTL Workflow folgt derselben Kette: Etwas passiert, Regeln filtern, Aktionen greifen. Wer diese drei Bausteine trennt, erkennt später schneller, warum ein Workflow mehrfach läuft oder ausbleibt.
Ereignisse wie Auftrag erstellt/geändert, Artikel speichern, manuell oder zeitgesteuert.
Shop, Land, Status, Attribut, Zahlungsart oder DotLiquid-Werte entscheiden über den Lauf.
Wert setzen, E-Mail, Druck, Ausführen (Programm/Skript) oder CustomWorkflows.
Sobald eine Aktion denselben Auslöser erneut erzeugt, drohen Endlosschleifen. Deshalb gehören idempotente Bedingungen und klare Zielzustände von Anfang an dazu – Details dazu stehen weiter unten und in den Helpdesk-Artikeln zu Workflow-Struktur.
Mit nativen Aktionen lassen sich viele Alltagsregeln abbilden: Versandart setzen, Hinweise pflegen, E-Mails auslösen, Etiketten drucken oder Aufträge nach Regeln kennzeichnen.
Ein bewährtes Muster ist, komplexe Regeln nicht in vielen parallelen „Auftrag erstellt“-Workflows zu verteilen, sondern in einem zentralen manuellen Workflow zu bündeln und von Ereignissen nur zu referenzieren. So bleibt die Pflege beherrschbar – beschrieben als Best Practice zur Versandart ermitteln und setzen.
Auch gezielte Belege und Statuswechsel gehören dazu, etwa wenn Workflows nur für bestimmte Rechnungskorrekturen laufen sollen. Die Grenzen beginnen, wenn Werte dynamisch berechnet, shopbezogen gesetzt oder außerhalb der Wawi verarbeitet werden müssen.
Standardaktionen stoßen an Grenzen, wenn Werte dynamisch aus mehreren Feldern berechnet werden müssen, shopbezogene Attribute gesetzt werden sollen oder Prozesse Systeme außerhalb der Wawi berühren.
Ein typisches Beispiel: Funktionsattribute pro Shop. Die native Aktion setzt oft nur den globalen Wert. Ab Wawi 1.6 helfen CustomWorkflows mit SQL-Prozeduren – dokumentiert unter Funktionsattribute für Shops per Workflow setzen.
Ebenso dynamische Zahlungsarten, gezielter Shopabgleich oder „Externe Rechnung“: Hier imitieren CustomWorkflows den fachlich korrekten Wawi-Pfad performant – mit dem Risiko, dass große JTL-Updates die kritische Stelle verändern und geprüft werden müssen.
Reicht die native Aktion nicht, öffnet die Aktion „Ausführen“ den Weg zu PowerShell, Programmen oder Encoded Scripts. Parameter kommen oft per DotLiquid aus dem Vorgang. Für sichere, wiederholbare Skripte eignet sich das T4DT PowerShell Framework mit Logging, Credential-Schutz und Fehlerbehandlung.
Ereignis, Bedingung und native Aktion in der Wawi.
Encoded Script, CustomWorkflows oder Framework-Jobs.
Shop-Queue, Partner, Monitoring oder Message-Schicht.
Technisch verbreitet: PowerShell.exe mit EncodedCommand und Echo-Parametern. Die Schrittfolge beschreibt der Helpdesk-Artikel Encoded Script in Ausführen Workflow einsetzen. Bei Bedarf wartet der Workflow auf Prozessende.
Zusätzlich lassen sich Workflows extern anstoßen – etwa über den JtlWorkflowButler per Event-ID. So entstehen zeitgesteuerte Hintergrundprozesse oder Ketten zwischen Objekten, ohne alles in einen einzigen Auslöser zu pressen.
Die folgenden Beispiele stammen aus dokumentierten T4DT-Lösungen und Supportfällen. Kundennamen bleiben anonym; beschrieben ist das technisch Wesentliche.
Ausgangslage: Mehrdimensionale Versandregeln (Land, Plattform, Gewicht, Maße) führten zu vielen parallelen Workflows und manuellen Korrekturen.
Auslöser: Auftrag erstellt und Auftrag geändert – jeweils mit Referenz auf einen zentralen manuellen Workflow.
Bedingungen: Kombinierte Regeln; der letzte zutreffende Zweig gewinnt.
Aktionen: Versandart setzen, sodass der Auftrag jederzeit einen eindeutigen Zustand hat.
Lösungsweg: Entscheidungsmatrix in einem manuell testbaren Workflow; Ereignisse nur referenzieren statt kopieren.
Nutzen: Weniger Chaos, konsistente Versandart nach jeder Änderung, einfachere Wartung.
Grenzen/Risiken: Falsch sortierte Zweige überschreiben sich; ohne klare Priorität entsteht „Zufallslogik“. Details: Best practice Versandart.
Ausgangslage: Aufträge im Gutschriftverfahren dürfen in der Wawi keine Rechnung erzeugen.
Auslöser: Auftragsbezogene Workflow-Ereignisse unter definierten Bedingungen.
Bedingungen: Fachliche Merkmale des Vorgangs (z. B. Abrechnungsart/Partnerlogik).
Aktionen: CustomWorkflow-Prozedur setzt den Zustand „Externe Rechnung“ analog zum Wawi-Dialog.
Lösungsweg: SQL-Aktion im Schema CustomWorkflows ab Wawi 1.6, performant und clientübergreifend verfügbar.
Nutzen: Sofortige Absicherung gegen fehlerhafte Rechnungserstellung.
Grenzen/Risiken: Abhängigkeit von internen Strukturen; nach größeren Wawi-Updates prüfen. Anleitung: Auftrag auf externe Rechnung setzen.
Ausgangslage: Staffel- und Kundengruppenpreise sowie Shop-Syncs mussten nach Import oder Artikeländerung gezielt laufen – nicht als globaler Komplettabgleich.
Auslöser: z. B. nach dem Speichern eines Artikels oder nach Import/Workflow-Start.
Bedingungen: Shopname, Kundengruppe, Staffelmenge und Netto-Preis per DotLiquid.
Aktionen: CustomWorkflow setzt Preise; optional schreibt eine weitere Prozedur den Artikel in die Shop-Queue (Preis-/Bestand-/Komplettabgleich wählbar).
Lösungsweg: Typisierte Parameter und Prozeduren in CustomWorkflows; Shopansprache über Namen statt interner IDs.
Nutzen: Automatisierte Preispflege und gezielter Abgleich ohne Dauerlast.
Grenzen/Risiken: Falsche Shop-/Gruppennamen; eBay-/Amazon-Trigger werden dadurch nicht mit ausgelöst. Siehe Kundengruppenpreise per Workflow und Shopabgleich erzwingen.
Ausgangslage: Prüfungen oder Folgeprozesse (z. B. Adressvorschläge, Dateiexporte, externe Systeme) liegen außerhalb nativer Aktionen.
Auslöser: Manuelles Ereignis oder Vorgangsereignis mit Aktion „Ausführen“.
Bedingungen: Nur für relevante Aufträge/Status; Parameter aus Vorgangsdaten.
Aktionen: PowerShell Encoded Script mit Pflichtparametern; optional Warten auf Prozessende.
Lösungsweg: Skript-Encoding, Parameterreihenfolge wie im Script; Betrieb auf Basis des PowerShell Frameworks mit Logging und Fehlermails.
Nutzen: Komplexe Logik bleibt versionierbar und nachvollziehbar, ohne die Workflow-Oberfläche zu überladen.
Grenzen/Risiken: Rechte, ExecutionPolicy, Timeouts und fehlende Idempotenz. Einstieg: Encoded Script und PowerShell Framework.
Ausgangslage: Lieferantenbestellungen, Tracking und Bestände liefen per E-Mail/CSV zwischen Händler und Dropshipping-Partner.
Auslöser: Workflows in Beschaffung sowie Versand/Lieferschein nach Installation der Message-Gateways.
Bedingungen: Partner-Routen und aktivierte Nachrichtentypen.
Aktionen: Export/Import standardisierter Messages (Auftrag, Versand inkl. Tracking, optional Lagerbestand).
Lösungsweg: JTL-Workflows greifen in die Message-Schicht von t4data.cloud Messages; Status und Queue bleiben im Portal nachvollziehbar.
Nutzen: Weniger manuelle Erfassung, skalierbare Partneranbindung ohne Einzelschnittstelle je Lieferant.
Grenzen/Risiken: Beide Seiten brauchen Gateway, Partner-Route und klare Prozessverantwortung. Vertiefung: JTL-Dropshipping automatisieren.
Komplexe JTL Workflows scheitern selten an der ersten Idee – häufiger an Rückkopplung. Ändert eine Aktion Felder, die denselben Auslöser erneut feuern, plant der Worker den Workflow immer wieder neu.
Aktion erzeugt dasselbe Ereignis ohne geänderten Zielzustand.
Nur ausführen, wenn der Zielwert fehlt; Logik zentral referenzieren; manuell testen.
Weitere Fehlerquellen: zu viele parallele „Auftrag erstellt“-Workflows, fehlende Unterscheidung ähnlicher Belege und unkontrollierte Folgeaktionen über Ausführen-Skripte. Orientierung bietet die Kategorie JTL-Workflows sowie Tipps zu Endlosschleifen unter JTL Tipps & Tricks.
Schutzmaßnahmen: Idempotente Bedingungen, Stateful Zielwerte, Referenzieren statt Kopieren und klare Stopp-Kriterien für Skripte.
Native Workflows sind stark bei klaren Zustandswechseln in der Wawi. Sie sind schwächer bei shopbezogenen Sonderfällen, hohen Datenmengen mit dynamischer Logik und bei Prozessen, die Partner- oder Middleware-Systeme einschließen.
CustomWorkflows erweitern den Radius, bleiben aber update-sensitiv. PowerShell öffnet externe Welten, braucht aber Betriebskonzept: Rechte, Logging, Timeouts und Wiederanlauf.
Wer Datenaustausch zwischen Unternehmen automatisieren will, sollte prüfen, ob standardisierte Messages die bessere Schicht sind – nicht jeder Partnerbedarf gehört in einen Einzel-Workflow.
Testen Sie neue Regeln zuerst manuell und an wenigen Vorgängen. Zentrale manuelle Workflows sind dafür besser geeignet als viele versteckte Ereignis-Kopien.
PowerShell-Lösungen gehören mit Log und Fehlerbenachrichtigung betrieben. Für den Worker-Hintergrund eignen sich Statusabfragen – etwa zur Überfälligkeit von Abgleichen und Workflow-Queues, wie unter JTL Worker-Status per SQL beschrieben.
Überwachung heißt: erkennen, bevor Kunden es merken. Alarme auf Queue-Rückstau und fehlgeschlagene Skripte sind Teil einer belastbaren Automatisierung.
Ein Standardworkflow reicht, wenn Auslöser und Zielzustand stabil sind und native Aktionen den Fachfall abdecken. Individuelle Entwicklung wird wirtschaftlich, wenn dieselbe Ausnahme täglich Zeit kostet, Fehlerquote steigt oder mehrere Systeme synchron bleiben müssen.
Faustregel: Erst Prozess schärfen, dann Workflow. Danach Bordmittel, dann CustomWorkflows/PowerShell, dann Framework oder Message-Schicht. So vermeiden Sie teure Sonderlösungen für Probleme, die Struktur brauchen.
Für Beratung, Support und Umsetzung stehen JTL-Wawi-Support und die Automatisierungsprodukte von T4DT bereit – von Workflow-Design bis PowerShell Framework.
Was ist der Unterschied zwischen manuellem und ereignisbasiertem JTL Workflow?
Manuelle Workflows starten Sie gezielt – ideal zum Testen und als zentrale Logik. Ereignisbasierte Workflows reagieren automatisch auf Vorgänge. Best Practice ist oft: Logik manuell bündeln und von Ereignissen nur referenzieren.
Kann ich PowerShell fest in JTL-Wawi-Workflows einbinden?
Ja. Über die Aktion „Ausführen“ mit PowerShell.exe und Parametern bzw. Encoded Scripts. Für Betriebssicherheit empfiehlt sich ein Framework mit Logging und Credential-Schutz statt loser Einzelskripte.
Wie verhindere ich Endlosschleifen in Workflows?
Prüfen Sie, ob Aktionen denselben Auslöser erneut erzeugen. Setzen Sie Bedingungen so, dass die Aktion nur greift, wenn der Zielzustand noch fehlt. Vermeiden Sie unnötige Mehrfach-Workflows auf demselben Ereignis.
Wann sind CustomWorkflows sinnvoll?
Wenn native Aktionen den fachlichen Weg nicht abbilden – etwa dynamische Zahlungsarten, shopbezogene Attribute, gezielter Shopabgleich oder spezielle Auftragszustände. Voraussetzung sind passende Wawi-Version, Pro-Lizenz und Datenbankrechte sowie Update-Checks.
Wo finde ich konkrete JTL Workflow Beispiele zum Nachbauen?
Im T4DT Helpdesk unter der Kategorie JTL-Workflows sowie in den Auftrags- und Artikel-Workflow-Abschnitten. Dieser Blogbeitrag ordnet die Fälle strategisch ein; die Supportartikel liefern die technische Detailtiefe.
Wenn Sie JTL Workflows automatisieren und dabei Standard, PowerShell und individuelle Entwicklung sauber trennen wollen, sprechen Sie uns an. Wir prüfen Ist-Prozesse, Risiken und den wirtschaftlich sinnvollen Automatisierungsgrad.
Kontakt aufnehmen