Workflow Rules und Process Builder gehen in den Ruhestand

Die Gerüchteküche hat schon länger gebrodelt, doch jetzt tritt ein, was viele vermutet hatten: Workflow Rules und Process Builder werden durch Flow Builder abgelöst. Die Umstellung geht über einen längeren Zeitraum und in mehreren Schritten vonstatten. Einerseits, weil über die Jahre sehr viele Low-Code-Automatisierungen in genau diesen Tools produziert wurden, die man nicht ersatzlos löschen sollte.

Und zum anderen ist der Flow Builder für viele Nutzer noch ungewohntes Terrain, sodass betroffene Administratoren vor einem Lernprozess stehen, den es erst noch zu bewältigen gilt, bevor eine Migration ins Auge gefasst werden kann.

Warum?

Obwohl diese Ankündigung mit viel Aufwand für Salesforce-Kunden verbunden ist, dürfte es sich langfristig auszahlen, die Low-Code-Automatisierungstools unter ein Dach zu bringen. Mit nur einem Tool kann sich Salesforce bei der Weiterentwicklung auf genau das konzentrieren, wodurch sich Innovationen noch schneller realisieren lassen. Neben regelmäßigen Updates wird die Übersichtlichkeit der Low-Code-Automation verbessert, um die “Order-of-Execution” besser nachverfolgen und anpassen zu können. Zudem lässt sich im Vergleich zu Workflow Rules und Process Builder durch den Einsatz des Flow Builder die Performance verbessern.

Wann passiert was?

Workflow Rules: Der erste Schritt zur Abschaffung ist bereits durchgeführt. Salesforce hat mit dem Spring ’22 Release ein Tool für die Migration von Workflow Rules in Flow Builder herausgebracht. Gibt man im Setup/Quickfinder „Migrate” ein, wird einem das Tool „Migrate to Flow (Beta)” angezeigt. Hier lassen sich die bereits implementierten Workflow Rules anzeigen und in Flow migrieren.

Zusätzlich bietet das Migrationstool die Möglichkeit, den entstandenen Flow vor dem Speichern zu testen. Diese Option sollte nicht zuletzt mit Blick auf den Beta-Zustand des Tools ausgiebig genutzt werden. Die Migration funktioniert in vielen Fällen bisher nicht ohne weitere Bearbeitung des entstandenen Flows. Insbesondere sollte auch die Order of Execution der Automatisierungen dringlichst auf Herz und Nieren geprüft werden, um unerwünschte Nebeneffekte der Migration zu verhindern.

Zuletzt bietet das Migrationstool dem User an, migrierte Workflow Rules automatisiert zu löschen.

Process Builder: Im zweiten Schritt soll voraussichtlich im Summer ‘22 Release eine Erweiterung des Migrationstools implementiert werden, die einen ähnlichen Support für die Migration des Process Builder bietet. Ein konkretes Releasedatum steht noch aus und hängt vom Feedback zum jetzigen Umfang des Migrationstools ab.

Voraussichtlich mit dem Winter ‘23 Release, also Ende 2022 (!), wird Salesforce damit beginnen, das Erstellen von neuen Workflows und Processes zu blockieren. Bestehende Automatisierungen in Workflow und im Process Builder sollen vorerst weiter bestehen, ob diese noch bearbeitet werden können, ist aber wie der Zeitpunkt der kompletten Außerbetriebnahme fraglich.

Dieser grobe und recht langfristige Zeitrahmen ist von Salesforce bewusst gewählt, weil durch die Abschaltung dieser Tools den Salesforce-Kunden einiges an Aufwand bevorsteht - bestehende Automatisierungen müssen neu evaluiert werden, betroffene migriert bzw. angepasst werden und vor allem ausreichend getestet werden.

Wie sollte man weiter vorgehen?

Im ersten Schritt sollte geprüft werden, in welchem Maße die jeweiligen Instanzen betroffen sind. Je nach Umfang sollte evaluiert werden, welche Prozesse komplett neu überdacht werden müssen und in welchen Fällen eine “einfache” Migration zum Flow Builder ausreicht. Grundsätzlich empfiehlt sich dabei eine Evaluierung pro Objekt.

Kurzfristig sollten neue Automatisierungen für Objekte, bei denen bislang keine vorhanden war, mit dem Flow Builder umgesetzt werden.

Falls auf einem Objekt bereits schon ein Process Builder (oder Workflow Rules) hinterlegt wurde, sollte genau abgewogen werden, ob dieser bereits migriert werden kann oder zunächst weiterhin genutzt und editiert werden sollte, bis ein zeitlicher Rahmen für die Migration geschaffen werden kann.

Nach Möglichkeit sollten bereits jetzt alle Low-Code-Automatisierungen ausschließlich im Flow Builder umgesetzt werden, da es mittel- bis langfristig keine (Low-Code-)Alternative mehr geben wird. Das bedeutet für uns Admins: die Auswahl, welches Low-Code-Tool wir nutzen entfällt, trotzdem müssen wir abwägen, Entscheidungen treffen und uns an die Grundregeln halten: u. a. sollte die Anzahl der Flows pro Objekt so klein wie möglich (aber so groß wie nötig) sein (mehr hierzu in einem der kommenden Blogbeiträge).

Egal ob kurzfristig oder langfristig, jegliche Migration und/oder Anpassung sollte vorher IMMER ausgiebig getestet werden, damit man hinterher kein blaues Wunder erlebt.

Administratoren erhalten so die Möglichkeit, einen Frühjahrsputz in Sachen Automatisierungen durchzuführen und zwei Fliegen mit einer Klappe zu schlagen: die Performance wird verbessert und die „Order of Execution” kann verinnerlicht werden.

Hiervon dürften besonders Organisationen profitieren, die schon lange mit Salesforce arbeiten.

Allen, die Unterstützung und Beratung benötigen, stehen unsere Salesforce Experten gern zur Verfügung.

Fazit

Bye-bye Workflow Rules, Bye-bye Process Builder. Da es nur eine Frage der Zeit ist, wann beide komplett außer Betrieb genommen werden, sollte man mit der Migration zu Flow Builder möglichst bald beginnen, um Überraschungen frühzeitig entgegenzuwirken und von den zahlreichen Vorteilen des Flow Builders zu profitieren.