Salesforce Flow Builder: Automatisierungen ohne Code erstellen

Das Ende von Workflow Rules – Flow ist die Zukunft

Wenn du schon länger mit Salesforce arbeitest, kennst du vermutlich Workflow Rules und Process Builder. Beide Tools haben über Jahre hinweg gute Dienste geleistet, um einfache Automatisierungen abzubilden: Feld-Updates, E-Mail-Alerts, ausgehende Nachrichten. Doch Salesforce hat diese beiden Werkzeuge offiziell in den Ruhestand geschickt. Seit dem Spring '23 Release können keine neuen Workflow Rules oder Process Builder mehr erstellt werden – und bestehende sollen migriert werden.

Der Nachfolger heißt Flow Builder, und er ist nicht einfach nur ein Ersatz, sondern ein massives Upgrade. Der Flow Builder vereint die Funktionalität von Workflow Rules, Process Builder und Visual Workflow (ehemals Cloud Flow Designer) in einem einzigen, visuellen Tool. Und das Beste: Du brauchst keine Programmierkenntnisse, um damit komplexe Geschäftsprozesse abzubilden. Klicken statt coden – aber mit der Mächtigkeit, die man sonst nur von Apex-Code kennt.

In diesem Artikel gehe ich mit dir Schritt für Schritt durch die verschiedenen Flow-Typen, zeige dir, wie du deinen ersten Flow erstellst, und liefere dir drei konkrete Praxisbeispiele, die du sofort in deiner eigenen Salesforce-Org umsetzen kannst.

Flow-Typen im Überblick

Bevor wir in die Praxis einsteigen, ist es wichtig zu verstehen, welche Flow-Typen es gibt. Salesforce bietet fünf Haupttypen an, die sich in ihrem Auslöser und Einsatzzweck unterscheiden.

Record-Triggered Flows (Before Save und After Save)

Record-Triggered Flows sind der direkte Nachfolger von Workflow Rules und Process Builder. Sie werden automatisch ausgelöst, wenn ein Datensatz erstellt, aktualisiert oder gelöscht wird. Dabei gibt es zwei wichtige Varianten:

• Before Save: Der Flow läuft, bevor der Datensatz in die Datenbank geschrieben wird. Das ist ideal für Feld-Updates auf dem auslösenden Datensatz selbst, weil es keine zusätzliche DML-Operation (Datenbankschreibvorgang) verbraucht. Wenn du z.B. bei einer neuen Opportunity automatisch ein bestimmtes Feld befüllen willst, ist Before Save die richtige Wahl.
• After Save: Der Flow läuft, nachdem der Datensatz gespeichert wurde. Das brauchst du, wenn du andere Datensätze erstellen, aktualisieren oder löschen möchtest, E-Mails versenden oder externe Systeme aufrufen willst. Die meisten komplexeren Automatisierungen laufen im After-Save-Kontext.

Record-Triggered Flows sind das Arbeitspferd deiner Salesforce-Automatisierung. Sie decken vermutlich 70 bis 80 Prozent aller Automatisierungsanforderungen ab.

Screen Flows (interaktive Formulare)

Screen Flows sind interaktive Flows, die dem Benutzer ein oder mehrere Bildschirme anzeigen. Denk an sie wie an intelligente Formulare, die auf Benutzereingaben reagieren, Daten validieren und basierend auf den Antworten unterschiedliche Aktionen ausführen. Screen Flows eignen sich hervorragend für geführte Prozesse: Datenerfassung, Wizard-artige Abläufe, Konfigurationstools oder Self-Service-Portale.

Das Besondere an Screen Flows: Du kannst sie in Lightning Pages, Community-Seiten, Quick Actions oder sogar in Utility Bars einbetten. Damit werden sie zu einem flexiblen UI-Werkzeug, das weit über einfache Automatisierung hinausgeht.

Scheduled Flows (zeitgesteuert)

Scheduled Flows laufen zu festgelegten Zeiten – täglich, wöchentlich oder in einem benutzerdefinierten Intervall. Sie durchsuchen eine Menge von Datensätzen basierend auf definierten Kriterien und führen dann Aktionen für jeden passenden Datensatz aus. Typische Einsatzszenarien: Erinnerungen versenden, veraltete Datensätze bereinigen, regelmäßige Status-Updates durchführen oder periodische Reports generieren.

Autolaunched Flows (von anderen Prozessen aufgerufen)

Autolaunched Flows haben keinen eigenen Trigger – sie werden von anderen Prozessen aufgerufen. Das kann ein anderer Flow sein (als Subflow), ein Apex-Code, ein REST-API-Call oder ein Platform Event. Sie sind das Schweizer Taschenmesser für wiederverwendbare Logik. Wenn du einen bestimmten Prozess an mehreren Stellen brauchst, packst du ihn in einen Autolaunched Flow und rufst ihn von überall auf.

Platform Event-Triggered Flows

Platform Event-Triggered Flows reagieren auf Platform Events – Salesforces Implementierung eines Event-Bus-Systems. Sie eignen sich für Event-Driven Architectures, bei denen verschiedene Systeme über Events kommunizieren. In der Praxis ist das relevant, wenn du Salesforce mit externen Systemen integrierst oder lose gekoppelte Prozesse innerhalb von Salesforce aufbauen möchtest.

How-to: Deinen ersten Record-Triggered Flow erstellen

Genug Theorie – lass uns einen Flow bauen. Wir erstellen einen Record-Triggered Flow, der ausgelöst wird, wenn eine Opportunity auf "Closed Won" gesetzt wird. Der Flow soll dann automatisch den Account-Status aktualisieren.

Schritt 1: Flow Builder öffnen und Trigger konfigurieren

Navigiere in Salesforce zu Setup und suche nach "Flows". Klicke auf "New Flow" und wähle "Record-Triggered Flow". Im ersten Schritt konfigurierst du den Trigger:

• Object: Wähle "Opportunity"
• Trigger the Flow When: "A record is created or updated"
• Optimize the Flow for: "Actions and Related Records" (das ist der After-Save-Modus, den wir brauchen, weil wir den zugehörigen Account aktualisieren wollen)

Schritt 2: Entry Conditions festlegen

Jetzt definierst du, unter welchen Bedingungen der Flow tatsächlich laufen soll. Nicht jede Opportunity-Änderung soll den Flow auslösen – nur wenn die Stage auf "Closed Won" gesetzt wird. Konfiguriere die Entry Conditions wie folgt:

• Condition Requirements: All Conditions Are Met
• Field: StageName | Operator: Equals | Value: Closed Won

Aktiviere außerdem die Option "Only when a record is updated to meet the condition requirements". Damit stellst du sicher, dass der Flow nur läuft, wenn sich der Wert tatsächlich geändert hat – nicht bei jedem Speichern einer bereits gewonnenen Opportunity.

Schritt 3: Actions hinzufügen

Jetzt kommt das Herzstück: die Aktionen. Füge ein "Update Records"-Element hinzu und konfiguriere es:

• Label: "Update Account Status"
• How to Find Records: "Specify conditions to identify records, and set fields individually"
• Object: Account
• Filter: Id equals {!$Record.AccountId} (das verknüpft den Account mit der Opportunity)
• Field: Status__c (oder dein benutzerdefiniertes Feld) | Value: "Kunde"

Du kannst weitere Aktionen hinzufügen – etwa eine E-Mail versenden (über ein "Send Email"-Element oder eine E-Mail-Alert-Action) oder einen Task erstellen (über ein "Create Records"-Element). Jede Aktion wird als separates Element im Flow-Canvas angezeigt und nacheinander ausgeführt.

Schritt 4: Decision Elements für Verzweigungen

Was, wenn du unterschiedliche Aktionen basierend auf bestimmten Bedingungen ausführen möchtest? Dafür gibt es das Decision-Element. Ziehe ein Decision-Element auf den Canvas und definiere verschiedene Outcomes. Zum Beispiel:

• Outcome 1: "Großer Deal" – Bedingung: Amount > 50.000 Euro
• Outcome 2: "Standard Deal" – Bedingung: Amount <= 50.000 Euro
• Default Outcome: Fängt alle übrigen Fälle auf

Für jeden Outcome kannst du dann unterschiedliche Aktionen definieren. Bei großen Deals vielleicht eine Benachrichtigung an die Geschäftsführung, bei Standard-Deals eine reguläre Willkommens-E-Mail. Decision Elements machen deine Flows intelligent und flexibel.

How-to: Screen Flow für Datenerfassung

Der zweite Flow-Typ, den du unbedingt beherrschen solltest, ist der Screen Flow. Lass uns einen bauen, der es dem Vertrieb ermöglicht, neue Leads strukturiert zu erfassen.

Screen-Elemente konfigurieren

Erstelle einen neuen Flow vom Typ "Screen Flow". Ziehe ein Screen-Element auf den Canvas. Innerhalb des Screens stehen dir zahlreiche Eingabekomponenten zur Verfügung:

• Text Input: Für Freitextfelder wie Name, Firma, E-Mail
• Picklist: Für Auswahlfelder wie Branche, Lead Source oder Produkt-Interesse
• Lookup: Für die Suche nach bestehenden Datensätzen – z.B. um den Lead einem bestehenden Account zuzuordnen
• File Upload: Für Datei-Uploads, etwa Visitenkarten oder Dokumente
• Number, Date, Checkbox: Für numerische Eingaben, Datumsfelder und Ja/Nein-Entscheidungen
• Display Text: Für erklärende Texte oder Hinweise zwischen den Eingabefeldern

Jedes Eingabeelement speichert den eingegebenen Wert automatisch in einer Flow-Variable, die du in späteren Schritten verwenden kannst.

Mehrseitige Flows

Für komplexere Erfassungsprozesse kannst du mehrere Screens hintereinanderschalten. Das ist besonders nützlich, wenn du den Benutzer schrittweise durch einen Prozess führen willst – wie ein Wizard. Zwischen den Screens kannst du Decision-Elemente einbauen, die basierend auf den bisherigen Eingaben entscheiden, welcher Screen als Nächstes angezeigt wird. So erstellst du dynamische, kontextabhängige Formulare, die den Benutzer nicht mit irrelevanten Feldern überfordern.

Ein Beispiel: Auf Screen 1 fragt der Flow nach der Unternehmensgröße. Wenn der Benutzer "Enterprise (500+ Mitarbeiter)" auswählt, zeigt Screen 2 erweiterte Felder für Enterprise-Anforderungen an. Bei "KMU (unter 50 Mitarbeiter)" erscheint ein vereinfachter Screen 2. So bekommt jeder Lead genau die richtigen Fragen.

Flow in Lightning Page einbetten

Ein Screen Flow, der irgendwo im Setup versteckt ist, wird nicht genutzt. Deshalb ist es wichtig, den Flow dort einzubetten, wo dein Team arbeitet. Die gängigsten Optionen sind:

• Lightning Record Page: Bette den Flow direkt auf einer Account-, Kontakt- oder Lead-Detailseite ein. So hat der Vertrieb den Flow immer im Blick.
• Lightning App Page: Erstelle eine dedizierte Seite für den Flow, z.B. als "Neue Lead-Erfassung"-Tab.
• Quick Action: Mache den Flow über einen Button in der Salesforce-Aktionsleiste verfügbar.
• Home Page: Für häufig genutzte Flows eignet sich die Startseite besonders gut.

Um einen Flow einzubetten, öffne den Lightning App Builder, ziehe die "Flow"-Komponente auf die Seite und wähle deinen Flow aus. Du kannst dabei auch Input-Variablen konfigurieren, um dem Flow Kontext mitzugeben – etwa die Record-ID des aktuellen Datensatzes.

Praxisbeispiel 1: Opportunity gewonnen – automatischer Onboarding-Prozess

Lass uns die Theorie in die Praxis umsetzen. Ein klassisches Szenario: Wenn eine Opportunity auf "Closed Won" gesetzt wird, soll Folgendes automatisch passieren:

• Der Account-Status wird auf "Kunde" aktualisiert
• Eine Willkommens-E-Mail wird an den primären Kontakt gesendet
• Ein Onboarding-Task wird für den Account Owner erstellt

Erstelle einen Record-Triggered Flow mit dem Trigger auf Opportunity (After Save), Entry Condition: StageName = "Closed Won" (nur bei Änderung). Dann fügst du drei Aktionen nacheinander hinzu:

Aktion 1 – Update Records: Aktualisiere den zugehörigen Account. Setze das Status-Feld auf "Kunde" und optional das Feld "Kunde seit" auf das heutige Datum mit der Formel {!$Flow.CurrentDate}.

Aktion 2 – Send Email (oder Email Alert Action): Verwende eine vordefinierte E-Mail-Vorlage für die Willkommensnachricht. Die Empfänger-E-Mail holst du über eine Get-Records-Aktion, die den primären Kontaktperson des Accounts abfragt. Alternativ kannst du den Contact Role der Opportunity nutzen.

Aktion 3 – Create Records: Erstelle einen neuen Task mit dem Subject "Onboarding durchführen", dem Due Date 7 Tage in der Zukunft, dem Status "Not Started" und dem Owner = Account Owner. In der Beschreibung kannst du automatisch den Opportunity-Namen und den Deal-Wert einfügen, damit der zuständige Mitarbeiter sofort Kontext hat.

Dieser Flow ersetzt einen manuellen Prozess, der vorher drei separate Schritte erforderte – und dabei fehleranfällig war, weil Schritte vergessen wurden. Jetzt passiert alles automatisch und konsistent.

Praxisbeispiel 2: Lead-Qualifizierung per Screen Flow

Das zweite Praxisbeispiel zeigt die Stärke von Screen Flows im Vertriebsalltag. Die Herausforderung: Dein Vertriebsteam soll eingehende Leads qualifizieren, bevor sie konvertiert werden. Anstatt das über verschiedene Felder auf dem Lead-Record zu machen, erstellst du einen geführten Qualifizierungsprozess.

Der Screen Flow besteht aus drei Screens:

Screen 1 – Grundqualifizierung: Der Vertriebsmitarbeiter beantwortet Fragen wie: "Hat der Lead ein konkretes Budget?", "Gibt es einen Entscheidungszeitraum?", "Wer ist der Entscheider?" – klassische BANT-Kriterien. Jede Frage ist ein Picklist- oder Checkbox-Element.

Screen 2 – Bedarfsanalyse: Basierend auf den Antworten von Screen 1 werden kontextspezifische Folgefragen angezeigt. Wenn ein Budget vorhanden ist, fragt der Flow nach der Größenordnung. Wenn ein Entscheidungszeitraum genannt wurde, nach dem genauen Datum. Hier nutzt du ein Decision-Element zwischen Screen 1 und Screen 2, um den richtigen Screen anzuzeigen.

Screen 3 – Zusammenfassung und Aktion: Der Flow zeigt eine Zusammenfassung aller Eingaben an und bietet zwei Buttons: "Lead konvertieren" und "Lead zurückstellen". Bei "Lead konvertieren" ruft der Flow eine Apex-Invocable-Action auf, die den Lead automatisch in Account, Contact und Opportunity konvertiert. Bei "Lead zurückstellen" wird der Lead-Status aktualisiert und ein Follow-up-Task erstellt.

Diesen Screen Flow einbettest du als Quick Action auf dem Lead-Record. So kann der Vertrieb den Qualifizierungsprozess direkt aus dem Lead heraus starten – mit einem Klick auf "Lead qualifizieren". Das Ergebnis: konsistente Qualifizierung, bessere Datenqualität und ein schnellerer Vertriebsprozess.

Praxisbeispiel 3: Scheduled Flow für wöchentliches Pipeline-Cleanup

Das dritte Beispiel zeigt, wie du mit Scheduled Flows für Ordnung in deiner Pipeline sorgst. Das Problem kennt jeder Vertriebsleiter: Opportunities, die seit Wochen in der Pipeline stehen, ohne dass etwas passiert. Kein Anruf, keine E-Mail, kein Meeting – der Deal ist de facto tot, aber niemand räumt ihn auf.

Erstelle einen Scheduled Flow, der jeden Montag um 8:00 Uhr morgens läuft. Der Flow sucht nach Opportunities, die folgende Kriterien erfüllen:

• StageName ist nicht "Closed Won" und nicht "Closed Lost"
• LastActivityDate liegt mehr als 30 Tage in der Vergangenheit (oder ist leer)
• CloseDate liegt in der Vergangenheit

Für jede gefundene Opportunity führt der Flow folgende Aktionen aus:

Aktion 1 – Update Records: Setze ein benutzerdefiniertes Checkbox-Feld "Stale_Opportunity__c" auf true. Damit kannst du diese Opportunities in Reports und Dashboards separat auswerten.

Aktion 2 – Create Records: Erstelle einen Task für den Opportunity Owner mit dem Subject "Pipeline-Review: [Opportunity Name] seit 30+ Tagen inaktiv". Das Due Date ist der aktuelle Tag, die Priorität "High".

Aktion 3 (optional) – Send Email: Sende eine zusammenfassende E-Mail an den Vertriebsleiter mit der Anzahl der markierten Opportunities. Dafür nutzt du einen Loop, der die Opportunities zählt, und ein abschließendes E-Mail-Element.

Das Ergebnis: Jeden Montag startet dein Team mit einem sauberen Überblick über inaktive Deals. Nichts fällt mehr unter den Tisch, und der Vertriebsleiter hat immer aktuelle Daten zur Pipeline-Hygiene.

Fortgeschrittene Techniken

Subflows für Wiederverwendbarkeit

Wenn du merkst, dass du die gleiche Logik in mehreren Flows brauchst, ist es Zeit für Subflows. Ein Subflow ist ein Autolaunched Flow, der von anderen Flows aufgerufen wird – ähnlich wie eine Funktion in der Programmierung. Definiere Input- und Output-Variablen, und rufe den Subflow über das "Subflow"-Element auf.

Ein klassisches Beispiel: Du hast einen Subflow, der einen Benachrichtigungsprozess abbildet – inklusive Empfänger-Ermittlung, Template-Auswahl und Versand. Diesen Subflow rufst du dann aus verschiedenen Record-Triggered Flows auf, die alle eine Benachrichtigung versenden müssen. Änderungen am Benachrichtigungsprozess musst du nur einmal im Subflow machen – alle aufrufenden Flows profitieren automatisch.

Collection Variables und Loops

Für Szenarien, in denen du mehrere Datensätze verarbeiten musst, brauchst du Collection Variables und Loop-Elemente. Eine Collection Variable ist im Grunde eine Liste von Datensätzen oder Werten. Du befüllst sie z.B. über ein "Get Records"-Element, das mehrere Datensätze abfragt.

Mit dem Loop-Element iterierst du über diese Collection und führst für jeden Datensatz Aktionen aus. Dabei ist es wichtig, dass du Updates nicht innerhalb des Loops ausführst (das würde eine DML-Operation pro Iteration verursachen und schnell an Governor Limits stoßen), sondern die zu aktualisierenden Datensätze in einer separaten Collection sammelst und nach dem Loop in einer einzigen Update-Aktion speicherst. Das nennt sich Bulkification – eines der wichtigsten Konzepte für performante Flows.

Custom Error Handling mit Fault Paths

Was passiert, wenn ein Flow fehlschlägt? Standardmäßig sieht der Benutzer eine generische Fehlermeldung – nicht gerade hilfreich. Mit Fault Paths kannst du eigene Fehlerbehandlung einbauen. Jedes Element im Flow hat einen Fault Connector, den du aktivieren kannst. Wenn das Element fehlschlägt, folgt der Flow dem Fault Path statt dem regulären Pfad.

Im Fault Path kannst du dann gezielt reagieren: eine verständliche Fehlermeldung anzeigen (bei Screen Flows), eine Benachrichtigung an den Admin senden, den Fehler in einem benutzerdefinierten Objekt loggen oder alternative Aktionen ausführen. Gutes Error Handling unterscheidet einen professionellen Flow von einem Bastel-Flow.

Best Practices und häufige Fehler

Bulkification beachten

Der häufigste Fehler bei Flows: DML-Operationen oder SOQL-Queries innerhalb von Loops. Salesforce hat strikte Governor Limits – maximal 150 DML-Operationen und 100 SOQL-Queries pro Transaktion. Wenn dein Flow in einem Loop für jeden Datensatz einzeln ein Update macht, knallt es spätestens bei 150 Datensätzen.

Die Lösung: Sammle alle Änderungen in einer Collection Variable innerhalb des Loops und führe das Update nach dem Loop einmal gebündelt aus. Ebenso bei Get Records: Hole alle benötigten Datensätze vor dem Loop in einer einzigen Abfrage.

Governor Limits verstehen

Neben DML und SOQL gibt es weitere Limits, die du kennen solltest: CPU-Zeitlimit (10 Sekunden für synchrone Transaktionen), Heap-Größe (6 MB synchron), maximale Flow-Interviews pro Transaktion und mehr. Für die meisten Standard-Flows sind diese Limits kein Problem. Aber bei komplexen Flows mit vielen Loops, Get Records und Subflows solltest du die Limits im Blick behalten.

Ein praktischer Tipp: Nutze den Debug-Modus des Flow Builders. Wenn du einen Flow testest, zeigt dir der Debug-Log detailliert an, wie viele SOQL-Queries und DML-Operationen verbraucht wurden. So erkennst du Probleme frühzeitig.

Testing und Debugging im Flow Builder

Salesforce bietet im Flow Builder einen integrierten Debug-Modus. Klicke auf "Debug" in der oberen Leiste, wähle einen Testdatensatz (bei Record-Triggered Flows) und starte den Durchlauf. Der Flow Builder zeigt dir visuell, welchen Pfad der Flow genommen hat, welche Werte die Variablen haben und wo eventuell Fehler aufgetreten sind.

Für Record-Triggered Flows empfehle ich zusätzlich, den Flow zunächst als "Inactive" zu speichern und in einer Sandbox zu testen. Aktiviere den Flow erst, wenn du ihn gründlich getestet hast – am besten mit verschiedenen Szenarien: Standardfall, Grenzfall und Fehlerfall. Und vergiss nicht: Record-Triggered Flows laufen im Kontext des auslösenden Benutzers. Teste also auch mit verschiedenen Benutzerberechtigungen, um sicherzustellen, dass der Flow für alle relevanten User funktioniert.

Flow Builder ist eines der mächtigsten Werkzeuge in der Salesforce-Plattform – und gleichzeitig eines der zugänglichsten. Du brauchst keinen Entwicklerhintergrund, um damit echten Mehrwert zu schaffen. Was du brauchst, ist ein solides Verständnis der Flow-Typen, der Best Practices und der Salesforce-Datenarchitektur. Wenn du diese Grundlagen beherrschst, kannst du Prozesse automatisieren, die vorher manuell, fehleranfällig und zeitaufwändig waren.

Der Schlüssel liegt darin, klein anzufangen. Starte mit einem einfachen Record-Triggered Flow, der ein Feld aktualisiert. Dann erweitere ihn Schritt für Schritt um weitere Aktionen, Entscheidungen und Subflows. Mit jedem Flow lernst du dazu – und mit jedem automatisierten Prozess sparst du deinem Team wertvolle Zeit.