Process Builder Pattern
In unserem einführenden Artikel Salesforce Prozessautomatisierung 2.0 haben wir die grundsätzlichen Chancen und Probleme der Prozessautomatisierung in Salesforce erläutert. Nun beginnen wir mit einem Deep Dive in das Thema Process Builder und Process Hierarchies in Salesforce und stellen unser Salesforce Process Builder Pattern als Lösungsansatz vor.
Ausgangslage
Wie werden Prozesse im Process Builder normalerweise erstellt und gemanaged? Ein Prozess in Salesforce besteht grundlegend aus den folgenden Komponenten:
- Object: Welches Salesforce Objekt startet die Automatisierung?
- Critera: Welche Kriterien muss der Record erfüllen, damit die Automatisierung startet?
- Action: Welche Aufgabe soll automatisch ausgeführt werden?
Für jeden Teilprozess wird ein neuer Flow erstellt. Unabhängig davon, ob sich Prozesse einzelne Informationen wie Object oder Criteria teilen. Das führt auf technischer Ebene zu zwei großen Problemen:
- Die Ausführungsreihenfolge ist nicht konfigurierbar
- Teilprozesse sind nicht verbunden und damit schlecht zu warten
Hinzu kommt eine Salesforce-spezifische Problemstellung, die alle Prozesse betrifft: Salesforce Prozesse lassen sich für das Debugging und Testing nicht aus dem Apex Code heraus deaktivieren. Dieses Problem erschwert es, Apex Klassen und Trigger in ihrem eigenen Kontext zu testen.
Lösungsansatz
Die Lösungsidee dieser Probleme teilt sich die Grundsätze mit den – im Salesforce Umfeld bekannten – Implementierungen eines Trigger Patterns. Im Prozessumfeld können wir jedoch fast gänzlich auf Code verzichten.
Jedes Objekt erhält seinen eigenen Prozess als Master, der die weitere Steuerung aller Subprozesse übernimmt. Über diesen Masterprozess lassen sich beispielsweise die Ausführungsreihenfolge und gemeinsame Criterias festlegen.
Umsetzung
Wir beginnen die Umsetzung mit der Erstellung eines Masterprozesses. Dieser zeigt auf ein spezifisches Objekt und wird aufgerufen, sobald ein Record erstellt oder verändert wird.
Prozesse ein- und ausschalten
Um Prozesse für einzelne Objekte deaktivierbar zu machen, legen wir zunächst ein Custom Setting an. Dieses Custom Setting enthält eine Checkbox für jeden Masterprozess. Wollen wir die Prozesse für einem Apex Test deaktivieren, so setzen wir die Checkbox des entsprechenden Custom Setting auf true. Um die Prozessautomatisierung durch den Process Builder zu deaktivieren, fragen wir Im Prozess ab, ob das entsprechende Custom Setting auf true oder false steht.
Ist das Custom Setting aktiviert, soll der Prozess abbrechen. Leider lässt sich ein Prozess ohne definierte Action nicht aktivieren. Wir benötigen eine Apex Klasse als Dummy, die unsere Daten nicht verändert. Diese kann wie folgt aussehen:
Mit dieser Klasse wird der Ausführungszweig geschlossen und sämtliche Prozesse auf diesem Objekt nicht ausgeführt. Der Zweig innerhalb des Masterprozesses kann dann zum Beispiel wie folgt aussehen:
Unterscheidung zwischen neuen und geänderten Records
Unser Masterprozess startet sowohl bei neu erstellten, als auch bei geänderten Datensätzen (Records). Um zwischen den beiden Varianten zu unterscheiden, müssen wir diese Abfrage innerhalb des Masterprozesses nachbauen. Dies erfolgt als einfaches Criteria innerhalb des Prozesses.
Ausführungsreihenfolge bestimmen
Um die Ausführung einzelner Subprozesse selbst zu steuern, nutzen wir ein mächtiges Werkzeug im Process Builder: Die Invocable Processes.
Jeder Subprocess wird als aufrufbarer Prozess definiert. Er enthält dasselbe Objekt wie der Masterprozess und wird entsprechend der Anforderungen an Criterias und Actions definiert. Diese Subprozesse können nun in gewünschter Reihenfolge aus dem Masterprozess gestartet werden. Wichtig hierbei ist, dass jeder Ausführungszweig weitergeführt wird, da die Abarbeitung der einzelnen Ausführungszweige (beginnend mit den formulierten Criterias) sonst nicht mehr abgearbeitet wird.
Ein Ausführungsbaum, der bei allen neuen Records ausgeführt wird und eine gewünschte Ausführungsreihenfolge definiert, kann wie folgt aussehen:
Zusammenfassung
Fügt man alle erläuterten Teilschritte zusammen, erhält man ein mächtiges Entwurfsmuster, welches ermöglicht, viele Hürden der Prozessautomatisierung in Salesforce zu umgehen. Darüberhinaus steigt die generelle Qualität der Prozessautomatisierung vor allem in komplexen Salesforce Organisationen um ein Vielfaches.
Zum generellen Verständnis dient folgende Grafik, welche das Vorgehen nochmals bildlich erläutert:
Sollten Sie weiterführende Fragen zum Process Builder Pattern oder anderen Salesforce-Themen haben, nehmen Sie gerne Kontakt zu uns auf. Wir freuen uns auf Ihre Anfrage!
Hallo Christian,
finde ich super, dass Ihr euer Wissen & Erfahrung über solche Beiträge teilt! Habt ihr einen Newsletter?
Von den Themen würde mich hauptsächlich Zusammenfassungen der Neuerungen von Releases interessieren und eure Meinung dazu (z. B. Retirement of Process Visualizer).
Grüße
Marcel
Hallo Marcel,
vielen Dank für dein Feedback.
Einen Newsletter haben wir im Moment noch nicht, am besten schaust du immer wieder mal in unserem Blog vorbei.
Wir arbeiten gerade an einem Beitrag über verschiedene Neuerungen im aktuellen Release und werden diesen in Kürze veröffentlichen. Für Ideen und Themenwünsche kannst du uns auch direkt über unser Kontaktformular erreichen.
Viele Grüße
Christian