Salesforce Flow oder Apex: Kriterien für eine wartbare Automatisierung
Die kurze Antwort
Wähle die Lösung, die das verantwortliche Team bei der erwarteten Last zuverlässig ändern und prüfen kann. Eine einfache Fachregel spricht häufig für Flow. Verflochtene Abläufe können Apex oder eine gezielte Kombination rechtfertigen. Die vorhandene Automatisierung auf dem Objekt gehört immer in die Entscheidung.
Zuerst den bestehenden Ablauf verstehen
Bevor du einen weiteren Flow hinzufügst, zeichne den Weg einer Änderung auf: Wer ändert welchen Datensatz, welche Automatisierungen starten dadurch und welche weiteren Datensätze werden geschrieben? Ergänze Integrationen und geplante Imports. So wird sichtbar, ob die neue Anforderung lokal bleibt oder bestehende Abläufe erneut auslöst.
Salesforce empfiehlt, Automatisierungsdichte und Abhängigkeiten gemeinsam zu betrachten. Der Leitfaden unterscheidet Flow, Flow mit aufrufbarem Apex und Apex-Trigger. Diese Einordnung ist eine Architekturhilfe, keine feste Regel allein anhand der Anzahl deiner Flows.
Vier Fragen für die Entscheidung
Die folgende Prüfliste ist mein Vorschlag für ein Architekturgespräch. Sie ersetzt keine Analyse der konkreten Organisation.
| Frage | Was du festhalten solltest |
|---|---|
| Wer wartet den Ablauf? | Benannte Verantwortliche, Kenntnisse in Flow oder Apex, Übergabe und Vertretung. |
| Wie verändert sich das Volumen? | Einzelbearbeitung, typische Imports und die größte realistische Transaktion. |
| Was muss gemeinsam gelingen? | Welche Änderungen zusammen erfolgreich sein müssen und wie Fehler sichtbar werden. |
| Was ändert sich voraussichtlich? | Regeln, die Fachanwender häufig anpassen, und stabile technische Verarbeitung getrennt betrachten. |
Beispiel: Zuständigkeit anhand eines Landes festlegen
Angenommen, eine Organisation möchte aus einer gepflegten Zuordnung von Land zu Zuständigkeit einen Zielwert ableiten. Zuerst klärst du die Fachregel: Was passiert bei unbekanntem Land, fehlender Zuordnung oder einer bereits manuell vergebenen Zuständigkeit? Ohne diese Antworten ist weder ein Flow noch Apex vollständig.
Für einen überschaubaren Ablauf würde ich zunächst einen Flow-Prototyp prüfen. Wächst die Anforderung zu einer komplexen Verteilung über mehrere Objekte, vergleiche ich eine gekapselte Apex-Funktion mit einer rein deklarativen Lösung. Das ist ein illustratives Szenario, kein getestetes Rezept und kein Kundenfall.
Ein anderes Werkzeug löst kein Transaktionsproblem
Flow und Apex innerhalb derselben Transaktion teilen sich relevante Plattformgrenzen. Eine ausgelagerte Apex-Aktion bekommt dadurch kein unabhängiges Budget. Untersuche deshalb die gesamte Verarbeitung statt nur die letzte Fehlermeldung.
Asynchrone Verarbeitung verändert außerdem den Ablauf: Ein späterer Fehler ist vom ursprünglichen Speichern getrennt. Lege vorab fest, wie ausstehende Arbeit, Wiederholungen und dauerhaft gescheiterte Vorgänge erkennbar werden.
Salesforce Help: How Flows Run in Transactions · Salesforce Help: Per-Transaction Flow Limits
Vor dem Einsatz nachweisen
Für beide Varianten würde ich dieselben fachlichen Prüfungen verlangen:
- Ein einzelner Datensatz und ein repräsentativer Import ergeben die erwartete Zuordnung.
- Unbekanntes Land und fehlende Konfiguration haben ein bewusst definiertes Ergebnis.
- Eine erneute Ausführung erzeugt keine unerwünschten Folgeänderungen.
- Ein Fehler ist für die zuständige Person nachvollziehbar; Wiederaufnahme und Rücknahme sind beschrieben.
- Die Lösung ist mit den relevanten Berechtigungen und den übrigen Automatisierungen geprüft.
Grenzen und Geltungsbereich
Diese Entscheidungshilfe bezieht sich auf durch Datensatzänderungen ausgelöste Automatisierung. Screen Flows und andere Auslöser brauchen eine eigene Betrachtung.
Die Beispiele wurden nicht in einer Salesforce-Organisation ausgeführt. Es wird keine Kompatibilität mit einem bestimmten Release behauptet. Vor einer Umsetzung sind aktuelle Plattformgrenzen und die konkrete Organisation zu prüfen.