Flows sind die mächtigste Waffe im Salesforce-Admin-Arsenal. Und gleichzeitig die Quelle der meisten Frust-Momente. Ich sehe das in jedem Org-Audit: Wer Flows beherrscht, automatisiert 80 % der Business-Logik ohne eine Zeile Code. Wer sie nicht beherrscht, baut sich ein Wartungs-Monster, das nach sechs Monaten niemand mehr anfassen will.
In dutzenden Org-Audits und Migrationsprojekten habe ich Muster erkannt. Was funktioniert, was schiefgeht, und wo die meisten Admins unnötig Zeit verlieren. Dieser Leitfaden ist das Destillat dieser Erfahrung. Und der erste Teil meiner dreiteiligen Flow-Serie.
Hier klären wir die strategischen Grundlagen: Welchen Flow-Typ setzen Sie wann ein, wie sieht eine saubere Architektur aus, und wie migrieren Sie weg von Process Builder und Workflow Rules. In Teil 2 geht es dann ans praktische Bauen. Vom Solution Design bis zum fertigen Flow. Und in Teil 3 zeige ich Ihnen, wie Sie typische Fehler vermeiden und Ihre Flows auf Performance trimmen.
Welcher Flow-Typ für welches Problem
Salesforce bietet fünf Flow-Typen, und die Wahl des richtigen Typs ist die erste architektonische Entscheidung, die Sie treffen. Falsch gewählt, und Sie kämpfen gegen das Framework statt mit ihm.
Record-Triggered Flow. Das Arbeitstier. Ersetzt Process Builder und Workflow Rules vollständig. Alles, was bei einer Datenänderung passieren soll, gehört hierhin: Feldwerte setzen, Folge-Records erstellen, E-Mails versenden, Aufgaben zuweisen. Ein Beispiel aus der Praxis: das Arbeitstier. Ersetzt Process Builder und Workflow Rules vollständig. Alles, was bei einer Datenänderung passieren soll, gehört hierhin: Feldwerte setzen, Folge-Records erstellen, E-Mails versenden, Aufgaben zuweisen. Ein Beispiel aus der Praxis: Automatische Aufgabenzuweisung bei neuen Opportunities. Genau so ein Use Case, der mit einem Record-Triggered Flow in fünf Minuten steht. Record-Triggered Flows unterstützen zwei Timing-Optionen (Before Save und After Save) sowie Scheduled Paths für zeitversetzte Aktionen. Dazu gleich mehr.
Screen Flow. Für User-Interaktion. Formulare, Wizards, Datenerfassung mit Validierung. Screen Flows sind das Frontend-Tool für Admins. Sie können auf Lightning Pages, in Quick Actions, als eigenständige Seiten oder sogar in Experience Cloud Sites eingebettet werden. Besonders mächtig mit der für User-Interaktion. Formulare, Wizards, Datenerfassung mit Validierung. Screen Flows sind das Frontend-Tool für Admins. Sie können auf Lightning Pages, in Quick Actions, als eigenständige Seiten oder sogar in Experience Cloud Sites eingebettet werden. Besonders mächtig mit der Data Table-Komponente für interaktive Listen, die ich in einem separaten Artikel detailliert erkläre.
Scheduled Flow. Für Batch-Operationen. Tägliche Bereinigungen, wöchentliche Erinnerungen, monatliche Statusupdates. Scheduled Flows laufen zeitgesteuert und verarbeiten Records in Bulk. Ein typischer Use Case aus meiner Praxis: Jeden Morgen um 7 Uhr alle Opportunities prüfen, deren Close Date gestern war und die noch auf "Open" stehen. Automatisch den Owner benachrichtigen und das Stage auf "Expired" setzen. Ohne Scheduled Flow müsste das jemand manuell tun. Scheduled Flows laufen immer im System Context. Das bedeutet volle Berechtigungen, unabhängig vom User.
Autolaunched Flow. Backend-Logik ohne UI. Wird von anderen Flows, Apex-Code oder externen Systemen aufgerufen. Perfekt als Subflow für wiederverwendbare Logik. Ich nutze Autolaunched Flows zum Beispiel als zentrale "Notification Engine": Ein einziger Flow, der E-Mail-Benachrichtigungen formatiert und versendet, aufgerufen von fünf verschiedenen Record-Triggered Flows. Das eliminiert Copy-Paste und zentralisiert Änderungen an einem Ort.
Platform Event-Triggered Flow. Für Event-Driven Architecture. Reagiert auf Platform Events, also asynchrone Nachrichten. Relevant bei Integrationen mit externen Systemen oder wenn Sie Prozesse entkoppeln wollen. In der Praxis sehe ich sie am häufigsten bei ERP-Integrationen: Das externe System feuert ein Platform Event, und der Flow verarbeitet die eingehenden Daten. Läuft ebenfalls im System Context und ist damit ideal für Hintergrundverarbeitung.
Die Entscheidung in 10 Sekunden
| Situation | Flow-Typ |
|---|---|
| Etwas soll passieren, wenn ein Record erstellt/geändert wird | Record-Triggered |
| Ein User soll Daten eingeben oder eine Auswahl treffen | Screen Flow |
| Eine Aktion soll regelmäßig zeitgesteuert laufen | Scheduled |
| Wiederverwendbare Logik ohne UI | Autolaunched |
| Reaktion auf externe Events oder Entkopplung | Platform Event-Triggered |
Flow-Architektur: So vermeiden Sie das Chaos
Die Flow-Typen zu kennen ist der einfache Teil. Der schwierige Teil ist, sie so zu organisieren, dass Ihre Org auch in zwei Jahren noch wartbar ist. Hier die Regeln, die ich aus dutzenden Org-Audits destilliert habe.
Ein Record-Triggered Flow pro Objekt. Das ist die goldene Regel. Nicht fünf separate Flows auf dem Account-Objekt, die sich gegenseitig in die Quere kommen. Stattdessen: ein Flow mit Entry Conditions und Decision-Elementen, der alle Szenarien abdeckt. Das reduziert Debugging-Aufwand und verhindert Reihenfolge-Probleme. Wenn der Flow zu groß wird, lagern Sie Teillogik in Subflows aus. Aber der Einstiegspunkt bleibt einer.
Naming Convention einführen und durchsetzen. Mein bewährtes Schema: [Typ] [Objekt]: [Zweck]. Also "RTF Opportunity: UpdateAfterEdit" oder "ALF Contact: API Sync". Leerzeichen werden im API-Namen automatisch zu Unterstrichen. Klingt banal, aber wenn Sie 40 Flows in einer Org haben, ist eine konsistente Benennung der Unterschied zwischen Wartbarkeit und Chaos. Dasselbe gilt für Variablen: var_FirstName, col_Contacts, frm_DueDate. Präfixe zeigen sofort, was was ist. In Präfixe zeigen sofort, was was ist. In Teil 2 gehe ich detailliert auf Variablen-Naming ein.
Subflows statt Copy-Paste. Wenn Sie dieselbe Logik in drei Flows brauchen, extrahieren Sie sie in einen Autolaunched Flow und rufen ihn als Subflow auf. Klassiker: E-Mail-Benachrichtigungslogik, Validierungsregeln oder Territory-Zuweisungen. Dokumentieren Sie die Ein- und Ausgabe-Variablen im Description-Feld des Subflows, damit andere Admins sofort verstehen, wie man ihn aufruft.
Before vs. After Save. Der richtige Trigger. Before Save für alles, was Feldwerte auf dem auslösenden Record setzt. Kein DML nötig, performanter, weniger Governor Limits. After Save für alles, was Folge-Records erstellt, E-Mails versendet oder externe Systeme aufruft. Mischen Sie nicht wahllos. Das führt zu schwer nachvollziehbaren Seiteneffekten. Eine Faustregel: Wenn Sie nur Felder auf dem auslösenden Record ändern, nutzen Sie Before Save. Für alles andere After Save.
Flow-Beschreibungen pflegen. Jeder Flow hat ein Description-Feld. Nutzen Sie es. Schreiben Sie rein, was der Flow tut, warum er existiert, und wann er zuletzt geändert wurde. In einer Org mit 40+ Flows ist das der Unterschied zwischen "Kann ich diesen Flow löschen?" und "Ich weiß genau, was dieser Flow tut." Zukünftiges Sie wird Ihnen danken. Bei neuen Versionen nutzen Sie das separate Versions-Beschreibungsfeld für die Änderungshistorie.
Bulkification im Hinterkopf behalten. Flows sind standardmäßig bulk-safe. Salesforce führt sie automatisch für alle Records in einer Transaktion aus. Aber Vorsicht bei Loops: Wenn Sie innerhalb eines Loops DML-Operationen (Create/Update/Delete) oder SOQL-Queries ausführen, laufen Sie in Governor Limits. Die Lösung ist immer dieselbe: Collections befüllen und nach dem Loop eine einzige Bulk-Operation ausführen. Die Details dazu finden Sie in Salesforce führt sie automatisch für alle Records in einer Transaktion aus. Aber Vorsicht bei Loops: Wenn Sie innerhalb eines Loops DML-Operationen (Create/Update/Delete) oder SOQL-Queries ausführen, laufen Sie in Governor Limits. Die Lösung ist immer dieselbe: Collections befüllen und nach dem Loop eine einzige Bulk-Operation ausführen. Die Details dazu finden Sie in Teil 3 dieser Serie.
Von Process Builder und Workflow Rules migrieren
Salesforce hat Process Builder und Workflow Rules offiziell zum Sunset erklärt. Das ist keine Drohung. Es ist eine Deadline. Wenn Sie noch aktive Process Builder oder Workflow Rules haben, ist jetzt der richtige Zeitpunkt für die Migration.
Das Migrate to Flow Tool. Salesforce bietet ein eingebautes Tool, das Process Builder und Workflow Rules automatisch in Flows konvertiert. Es funktioniert für einfache Automatisierungen erstaunlich gut. Eine Workflow Rule mit einer Field Update-Aktion wird sauber zu einem Before Save Flow konvertiert. Bei komplexeren Process Buildern mit verschachtelten Kriterien, Invocable Actions oder Cross-Object-Updates stößt es an Grenzen. Dann müssen Sie manuell nacharbeiten. Mein Rat: Nutzen Sie das Tool als Startpunkt, aber überprüfen Sie jeden konvertierten Flow manuell, bevor Sie ihn aktivieren.
Migrationsstrategie: Nicht alles auf einmal. Der größte Fehler, den ich bei Migrationsprojekten sehe: alles gleichzeitig umstellen wollen. Stattdessen empfehle ich diese Reihenfolge:
- Inventar erstellen. Alle aktiven Workflow Rules und Process Builder auflisten. Welches Objekt, welcher Trigger, was tut die Automatisierung?
- Priorisieren. Einfache Workflow Rules zuerst. Die lassen sich oft 1:1 mit dem Migrate to Flow Tool konvertieren. Komplexe Process Builder als letztes.
- Pro Objekt migrieren. Nicht kreuz und quer. Nehmen Sie sich ein Objekt vor, migrieren Sie alle Automatisierungen, testen Sie gründlich, dann das nächste Objekt.
- Test-Strategie. Für jede migrierte Automatisierung: Before/After-Vergleich. Erstellen Sie einen Test-Record mit den alten Automatisierungen, notieren Sie das Ergebnis, deaktivieren Sie die alten, aktivieren Sie den Flow, erstellen Sie denselben Test-Record. Identisches Ergebnis? Weiter zum nächsten.
Häufige Stolperfalle: Reihenfolge der Ausführung. Wenn Sie Process Builder und Flows parallel auf demselben Objekt aktiv haben, wird es unberechenbar. Process Builder laufen nach Flows. Das führt zu subtilen Bugs, die schwer zu diagnostizieren sind. Deshalb: Pro Objekt komplett migrieren, nicht halb Flows und halb Process Builder laufen lassen.
Der Lohn der Mühe. Nach der Migration haben Sie ein einheitliches Automatisierungs-Framework. Kein Rätselraten mehr, ob eine Aktion von einem Workflow, einem Process Builder oder einem Flow ausgelöst wird. Alles an einem Ort, alles mit denselben Tools debugbar. Und Sie sind zukunftssicher. Salesforce investiert alle neuen Automatisierungs-Features ausschließlich in Flows. Die Salesforce investiert alle neuen Automatisierungs-Features ausschließlich in Flows. Die Deployment-Nachbereitung wird deutlich einfacher, wenn Sie nur noch eine Automatisierungstechnologie managen müssen.
Wie diese Serie aufgebaut ist
Dieser Artikel hat die strategischen Grundlagen gelegt: Sie wissen jetzt, welchen Flow-Typ Sie für welches Problem einsetzen, wie eine saubere Architektur aussieht, und wie Sie Process Builder und Workflow Rules migrieren.
In Teil 2: Salesforce Flows aufbauen wird es praktisch. Dort zeige ich Ihnen den Weg vom Requirement zum Solution Design, erkläre die Basiselemente des Flow Builders. Get Records, Decisions, Loops. Und teile fortgeschrittene Patterns wie dynamische Org-Links und monatliche Scheduled Flows.
In Teil 3: Salesforce Flow Best Practices geht es um Operational Excellence: Die häufigsten Flow-Fehler und wie Sie sie vermeiden, Loop-Optimierung und Bulkification im Detail, systematisches Debugging mit den neuen Flow Logs, und Performance-Patterns für wartbare Flows.
Häufige Fragen
Welchen Flow-Typ sollte ich als Admin als erstes lernen?
Record-Triggered Flows, weil sie Process Builder und Workflow Rules ersetzen und den größten praktischen Nutzen haben. Danach Screen Flows für geführte Benutzerinteraktionen. Mit diesen beiden Flow-Typen lösen Sie 80% aller Automatisierungsaufgaben.
Wie lange dauert es, Salesforce Flows zu beherrschen?
Einfache Flows können Sie nach 1-2 Wochen mit Trailhead und Praxis aufbauen. Komplexe Flows mit Fehlerbehandlung, bulkifizierten Datenbankoperationen und mehreren Objekten brauchen einige Monate praktische Erfahrung.
Gibt es Grenzen, was Flows in Salesforce können?
Ja: Governor Limits begrenzen SOQL-Queries (100 pro Transaction) und DML-Statements (150 pro Transaction). Sehr komplexe Logik oder Echtzeit-Integrationen sind manchmal nur mit Apex umsetzbar. Flows decken aber 90% der Admin-Anwendungsfälle ab.
Wie strukturiere ich eine Salesforce-Org mit vielen Flows übersichtlich?
Klare Namenskonventionen (z.B. Objekt_Trigger_Funktion), Flows in API-Versionen und Active/Inactive Status sauber verwalten, und eine interne Dokumentation führen. Bei mehr als 30 aktiven Flows ist eine Inventarisierung Pflicht.
Flows sind kein Feature, das man einmal lernt und dann beherrscht. Salesforce erweitert den Flow Builder mit jedem Release. Neue Elemente, bessere Debugging-Tools, mehr Möglichkeiten. Wenn Sie Ihre Org auf eine solide Flow-Architektur umstellen wollen. Sei es eine Migration von Process Builder, ein Audit Ihrer bestehenden Flows oder der Aufbau einer neuen Automatisierungsstrategie. Unterstütze ich Sie dabei. Von der Bestandsaufnahme über die Konzeption bis zum Go-Live.
