Klassische Workflows ablösen: welche zuerst?

In vielen gewachsenen Lösungen steckt ein Bestand an klassischen Workflows. Sie wurden gebaut als es noch kein Power Automate gab, sie laufen und niemand fasst sie gern an. Spätestens wenn eine Modernisierung ansteht kommt die Frage: Muss das alles umgebaut werden und womit fängt man an?

Die kurze Antwort: nicht alles und nicht sofort. Die lange Antwort hängt an einer Unterscheidung die in vielen Diskussionen untergeht.

Was Microsoft tatsächlich empfiehlt

Microsoft schreibt seit Jahren, dass neue Automatisierungen als Power-Automate-Flows statt als klassische Workflows angelegt werden sollen. Bestehende Hintergrund-Workflows soll man überprüfen und einen Ersatz durch Flows in Betracht ziehen (Microsoft Learn: Replace classic Microsoft Dataverse workflows with flows). Ein Enddatum für klassische Workflows hat Microsoft nicht genannt.

Das ist eine Empfehlung und keine Abschaltung. Wer jetzt in Panik den ganzen Bestand umbaut gibt Geld für etwas aus, das in vielen Fällen auch bei der nächsten fachlichen Änderung mitwandern könnte. Wer den Bestand dagegen ignoriert baut weiter auf einer Technik in die Microsoft nicht mehr investiert.

Hintergrund oder Echtzeit: die wichtigste Unterscheidung

Klassische Workflows gibt es in zwei Varianten. Hintergrund-Workflows laufen asynchron: Der Anwender speichert, arbeitet weiter und der Workflow folgt kurz danach. Echtzeit-Workflows laufen synchron in derselben Transaktion. Der Anwender wartet bis sie fertig sind und sie können sogar das Speichern mit einer Fehlermeldung abbrechen.

Für Hintergrund-Workflows ist Power Automate der natürliche Nachfolger. Ein Cloud Flow mit Dataverse-Auslöser startet ebenfalls kurz nach der Änderung und kann vieles, was der klassische Workflow nie konnte: Schleifen etwa oder Connectoren zu anderen Systemen.

Für Echtzeit-Workflows gilt das nicht. Power Automate läuft nicht synchron, das steht auch in Microsofts eigener Gegenüberstellung. Ein Flow kann also kein Speichern verhindern und keinen Wert setzen bevor der Datensatz geschrieben ist. Microsoft rät hier zu prüfen ob sich das Ziel oder ein Teil davon asynchron lösen lässt und weist darauf hin, dass synchrone Workflows erheblich zu Performance-Problemen beitragen. Was wirklich synchron bleiben muss braucht einen anderen Ersatz:

• Plugin: der klassische Weg für Logik in der Transaktion mit allen Möglichkeiten und dem Nachteil, dass es Entwickler und Quellcode braucht.
• Geschäftsregel mit Bereich Tabelle: für einfache Feldwerte und Prüfungen. Sie läuft dann auch auf dem Server und nicht nur im Formular.
• Low-Code-Plugin: Logik in Power Fx, die bei Datenereignissen einer Tabelle läuft. Microsoft führt diese Funktion derzeit als Vorschau, die nicht für den produktiven Einsatz gedacht ist (Microsoft Learn: Low-Code-Plug-Ins). Für Produktion also noch kein Ersatz.

Welche zuerst

Eine sinnvolle Reihenfolge ergibt sich aus Aufwand und Wirkung.

Inaktive Workflows und Entwürfe. Was nicht läuft muss nicht migriert werden. Hier reicht die Frage ob ihn jemand vermisst danach wird gelöscht. Das ist die billigste Verkleinerung des Bestands.

Echtzeit-Workflows mit breiten Auslösern. Ein synchroner Workflow welcher bei jeder Änderung (an vielen Feldern startet) bremst jeden Anwender bei jedem Speichern. Hier ist die Wirkung am größten. Oft zeigt die Durchsicht, dass der Großteil der Logik gar nicht synchron sein muss; dieser Teil wird ein Flow und nur der Rest bleibt in der Transaktion.

Workflows mit Custom Workflow Activities. Darin steckt kompilierter .NET-Code. Power Automate kann solche Aktivitäten nicht aufrufen. Wer hier umbaut muss den Code ohnehin anfassen und sollte vorher klären ob der Quellcode vorliegt.

Einfache Hintergrund-Workflows. E-Mails verschicken, Feldwerte setzen, Aufgaben anlegen oder Datensätze zuweisen. Technisch sind sie leicht zu ersetzen, aber haben auch keinen Zeitdruck. Sie werden sinnvollerweise neu gebaut wenn der zugehörige Prozess ohnehin geändert wird.

Welche bleiben dürfen

Es gibt Fälle in denen der klassische Workflow derzeit schlicht mehr kann. Microsofts Gegenüberstellung nennt etwa den Zugriff auf den Zustand des Datensatzes vor der Änderung und Wartebedingungen auf Spalten. Beides hat Power Automate nicht. Ein Workflow, der wartet bis ein Datum erreicht oder ein Status gesetzt ist lässt sich nachbauen (aber leider nicht eins zu eins). Wer solche Workflows umstellt muss außerdem klären was mit den Workflow Instanzen passiert die gerade warten.

Auch ein Hintergrund-Workflow, der seit Jahren fehlerfrei läuft und gut beschrieben ist darf bleiben. Er steht auf der Liste und wird bei der nächsten Überarbeitung ersetzt. Das ist keine Nachlässigkeit sondern eine Priorität.

Woran man den Bestand erkennt

Für die Sortierung braucht man je Workflow vier Angaben: Hintergrund oder Echtzeit, Auslöser, Status und ob eigener Code im Spiel ist. Alles davon steht im Lösungsexport und wird von D365 Audit geprüft.

Wie klassische Workflows in die übrige Liste der Auslaufmodelle passen steht unter Was sind veraltete Anpassungen?, die Reihenfolge einer größeren Modernisierung unter Upgrade von alten Lösungen.