Home2019April

Monat: April 2019

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:

Beispiel Salesforce Process Builder
  • 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:

Codeschnipsel APEX Dummymethode

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:

Beispiel Process Builder APEX Aufruf

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:

Beispiel Process Builder New Record

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:

Diagramm Salesforce Process Builder Pattern

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!

Salesforce Prozessautomatisierung 2.0

Prozessautomatisierung in Salesforce ist Fluch und Segen zugleich:

Was wäre ein Customer-Relationship-Management-System (CRM) ohne die Möglichkeit, Aufgaben automatisiert ablaufen zu lassen? An dieser Stelle nimmt uns Salesforce einen Großteil der Aufgaben ab und schafft damit Zeit für wichtigere Aufgaben.

Falsch angewandt, kann die Prozessautomatisierung im CRM die Wertschöpfungskette eines Unternehmens auch stark verlangsamen.

Vielleicht haben Sie sich in Ihrem Salesforce schon mit den Folgen schlecht implementierter Prozessautomatisierung auseinandersetzen müssen:

  • Undurchsichtige Änderungen von Daten im System
  • Fehlende oder falsche Ausführung von automatisierten Teilprozessen
  • Schwierige Reproduzierbarkeit von Fehlern
  • Händische Nachbearbeitung von Daten

Salesforce Tools zur Prozessautomatisierung

Salesforce gibt uns verschiedene Tools an die Hand, um Geschäftsprozesse in Salesforce abzubilden und zu automatisieren. 

  • Lightning Process Builder
  • Flows
  • Approval Processes
  • Apex Code

Jedes dieser Tools hat unterschiedlichen Anwendungsgebiete, Stärken und Schwächen. Die visuellen Werkzeuge für Flows und Prozesse haben viel Aufmerksamkeit von Salesforce erhalten und ihr Funktionsumfang hat sich stetig erweitert. Durch den Fokus auf diese Tools erkennen wir einen rasanten Anstieg an implementierten Prozessen bei unseren Kunden. Mit der steigenden Zahl implementierter Prozesse, steigen leider auch die oben genannten Probleme. 

Herausforderungen der Prozessautomatisierung

Weiterhin arbeiten oftmals verschiedene Salesforce Dienstleister im selben Salesforce, welche die beauftragte Prozessautomatisierung ohne Rücksicht auf bestehende Prozessimplementierungen umsetzen. Dieses Verhalten führt zu noch mehr Problemen und noch weniger Nachvollziehbarkeit.

Unser Lösungsansatz

Um diesen Folgen zu begegnen, haben wir eine Methodik geschaffen, um Prozesse in Salesforce zu strukturieren und deren Ausführung nachvollziehbar zu machen. Dieses Muster lässt sich sowohl auf bestehende, als auch auf neu zu implementierende Prozesse anwenden.

Was haben Sie von diesem Muster?

  • Verlässliche Prozessautomatisierung
  • Nachvollziehbare Reihenfolge bei automatisierten Teilprozessen
  • Bessere Wartbarkeit des Systems
  • Einfache Fehleranalyse
  • Simple Erweiterbarkeit
  • Kosten- und Zeitersparnis bei der Entwicklung Ihres Systems
  • Dienstleisterübergreifende Strukturen

Gerne analysieren wir Ihr Salesforce, geben Ihnen Feedback zum aktuellen Stand und erarbeiten gemeinsam eine Lösungsstrategie. Nehmen Sie dazu gerne Kontakt zu uns auf. 

Eine technische Erläuterung finden Sie im Artikel Process Builder Pattern.

Salesforce Berechtigungen über SOQL bestimmen

Viele Administratoren kennen das Problem: Ist eine Salesforce Organisation historisch gewachsen, fehlt irgendwann nicht nur ein übergreifendes Berechtigungskonzept, sondern es herrscht auch Unsicherheit über bisher vergebene Berechtigungen. Das kann schnell zu einem gravierenden Problem im Bereich Compliance und Fehleranalyse werden.

Problemstellung

Möchte man einem User beispielsweise die Berechtigungen für ein bestimmtes Objekt entziehen, nehmen viele Administratoren den langen Weg auf sich, sämtliche zugewiesenen Permission Sets händisch zu durchsuchen. Noch schwieriger wird es, wenn sich die folgende Fragestellungen stellt: 

Welche Profile oder Permission Sets vergeben Rechte für ein bestimmtes Objekt?

Spätestens hier ist der Umweg über eine manuelle Suche im System kaum mehr umsetzbar. Glücklicherweise liefert uns die hinter Salesforce stehende Datenbank die Möglichkeit, solche Fragen mit wenigen Klicks zu beantworten. 

Lösungsansatz

Salesforce behandelt Berechtigungen intern als eigenständige Datensätze, welche mit Profilen verknüpft sind (die wiederum mit Usern verknüpft sind). Diese Datensätze lassen sich über die Salesforce-eigene Datenbanksprache SOQL abfragen:

SELECT Id, IsOwnedByProfile, Label
FROM PermissionSet

Über das Feld IsOwnedByProfile können wir sofort sehen, ob es sich um eigenständige oder durch ein Profil vergebene Berechtigungssätze handelt:

SELECT Id, IsOwnedByProfile, Label
FROM PermissionSet
WHERE IsOwnedByProfile = TRUE

Mithilfe dieses Mittels können wir nun auch beispielhalft die folgende Fragen beantworten:

„Welche Nutzer haben Schreibzugriff auf Accounts? Und woher stammt diese Berechtigung?“

SELECT Assignee.Name, PermissionSet.Id, PermissionSet.IsOwnedByProfile, PermissionSet.Profile.Name, PermissionSet.Label
FROM PermissionSetAssignment
WHERE PermissionSetId
IN (SELECT ParentId
FROM ObjectPermissions
WHERE SObjectType = 'Account' AND
PermissionsRead = TRUE )

Auch komplexere Fragen lassen sich so leicht beantworten:

„Welche Felder auf Account kann Christian Blechert sehen und welche kann er verändern? Woher stammen diese Berechtigungen?“

SELECT Id, Field, SObjectType, PermissionsRead, PermissionsEdit, Parent.Label, Parent.IsOwnedByProfile
FROM FieldPermissions
WHERE (ParentId IN (
  SELECT PermissionSetId
  FROM PermissionSetAssignment
  WHERE Assignee.Name = 'Christian Blechert'))
AND (PermissionsRead = TRUE)
AND (SObjectType = 'Account')

Wie im einleitenden Absatz angemerkt, lässt sich die Fragestellung auch umkehren.

„Wie kann ich herausfinden, welche Profile Berechtigungen für ein spezifisches Objekt vergeben?“

SELECT Profile.Name FROM PermissionSet
WHERE IsOwnedByProfile = TRUE
AND Id IN (
  SELECT ParentId FROM ObjectPermissions
  WHERE PermissionsRead = TRUE
  AND SObjectType = 'Account'
)

Führen wir diese Anfrage in Salesforce – beispielsweise über die Workbench – aus, erhalten wir eine Auflistung aller Profile mit Zugriff auf das Standardobjekt Account:

results-2

Zusammenfassung

Das Zusammenspiel der klassischen Salesforce-Oberfläche, der dahinterliegenden Datenbank und von SOQL-Abfragen eröffnet viele Möglichkeiten, Datensätze und Informationen schnell anzuzeigen und gegebenenfalls zu verändern.

 

Erkennen Sie Hürden aus Ihrem Salesforce wieder oder wünschen eine detaillierte Aufarbeitung Ihres Berechtigungskonzepts? Wir unterstützen Sie gerne, melden Sie sich bei uns.