Salesforce Flows aufbauen: Vom Solution Design zum fertigen Flow

Sie wissen, welchen Flow-Typ Sie brauchen und wie eine saubere Architektur aussieht. Das haben wir in das haben wir in Teil 1 dieser Serie geklärt. Jetzt geht es ans Bauen. Vom ersten Requirement bis zum fertigen, getesteten Flow.

In meiner Beratungspraxis sehe ich immer wieder dasselbe Problem: Admins springen direkt in den Flow Builder und fangen an, Elemente zu ziehen. Ohne Plan. Ohne Designdokument. Drei Wochen später hat der Flow 60 Elemente, niemand versteht ihn mehr, und jede Änderung bricht etwas anderes. Dieser Artikel zeigt, wie Sie es richtig machen.

Vom Requirement zum Solution Design

Bevor Sie den Flow Builder öffnen, brauchen Sie Klarheit. Drei Fragen müssen beantwortet sein.

Was genau soll passieren?

Klingt offensichtlich, ist es aber nicht. "Wenn eine Opportunity geschlossen wird, soll eine Benachrichtigung rausgehen" reicht nicht. Welches Feld triggert den Flow? Welche Bedingungen müssen erfüllt sein? Wer wird benachrichtigt. Der Owner, der Account-Manager, oder beide? Was steht in der Nachricht?der Owner, der Account-Manager, oder beide? Was steht in der Nachricht?

Sammeln Sie die Anforderungen in einer strukturierten Tabelle: Objekt, Trigger, Bedingung, Aktion, Priorität. Das zwingt Sie und Ihre Stakeholder, konkret zu werden. Notieren Sie auch Randbedingungen: Wie viele Records sind betroffen. 10 oder 10.000? Muss die Aktion sofort passieren oder reicht zeitversetzt?10 oder 10.000? Muss die Aktion sofort passieren oder reicht zeitversetzt?

Gibt es schon eine Automatisierung auf diesem Objekt?

Prüfen Sie unter Setup > Flows, ob bereits ein Record-Triggered Flow auf dem Objekt existiert. Falls ja, erweitern Sie ihn. Ein Flow pro Objekt, wie in ein Flow pro Objekt, wie in Teil 1 beschrieben. Prüfen Sie auch Apex Triggers unter Setup > Apex Triggers. Und schauen Sie nach übrig gebliebenen Process Buildern. Die laufen nach Flows und können subtile Konflikte verursachen.

Dokumentieren Sie kurz, was Sie finden: "RTF_Opportunity_UpdateAfterEdit: Setzt Stage basierend auf Amount. Mögliche Erweiterung mit Subflow." Das spart Ihnen und dem nächsten Admin Zeit.

Flow oder Apex?

Die Faustregel: Wenn Sie unter 30 Elemente brauchen und keine komplexen Berechnungen über mehrere Ebenen nötig sind. Flow. Wenn Sie mit großen Datenmengen arbeiten (10.000+ Records pro Batch), verschachtelte Hierarchien traversieren oder externe APIs mit komplexer Fehlerbehandlung aufrufen müssen. Apex.Flow. Wenn Sie mit großen Datenmengen arbeiten (10.000+ Records pro Batch), verschachtelte Hierarchien traversieren oder externe APIs mit komplexer Fehlerbehandlung aufrufen müssen. Apex.Apex.

Für das Beste aus beiden Welten gibt es zwei Kombinationsmuster:

Flow ruft Apex auf: Ein Flow-Element ruft eine Invocable Apex-Methode auf. Ideal, wenn die Hauptlogik visuell bleiben soll, aber eine spezifische Berechnung Apex-Power braucht. Beispiel: Der Flow prüft "Closed Won", eine Apex-Klasse berechnet einen komplexen Rabatt.
Apex ruft Flow auf: Ein Apex-Trigger startet einen Autolaunched Flow. Nützlich, wenn Apex den Einstiegspunkt kontrollieren muss, die nachgelagerte Logik aber admin-wartbar sein soll.

Testen Sie Ihre Wahl: Simulieren Sie in der Sandbox mit 200 Datensätzen. Wenn der Flow Governor Limits sprengt (100 SOQL-Queries, 150 DML-Statements), ist Apex oder eine Optimierung nötig.

💡

Praxistipp: Testen Sie Ihren Flow schon in der Design-Phase mit realen Sandbox-Daten. Nicht erst nach dem Aktivieren in Produktion. Ein einfacher Before/After-Test mit 10 Records deckt 80 % aller Probleme auf, bevor sie Ihrem Team auffallen.

Die Basiselemente: Get Records, Decisions, Loops und Co.

Der Flow Builder hat eine überschaubare Anzahl an Kernelementen. Wenn Sie diese beherrschen, können Sie 90 % aller Anforderungen umsetzen.

Get Records holt Daten aus Salesforce. Sie definieren das Objekt, die Filterkriterien und ob Sie einen oder mehrere Records zurückbekommen wollen. Praxistipp: Setzen Sie Filter immer so eng wie möglich. AccountId = {!$Record.AccountId} AND IsActive__c = true statt nur AccountId = {!$Record.AccountId}. Das spart SOQL-Queries und vermeidet unerwünschte Treffer. Im Debugger sofort prüfen: Kommen die erwarteten Records zurück? Wenn nicht, Filter anpassen.

Decision lenkt den Flow basierend auf Bedingungen. Denken Sie an eine Weiche im Schienennetz. Bündeln Sie Bedingungen wo möglich: AND(StageName = 'Closed Won', Amount > 5000) ist ein Element statt zwei verschachtelter Decisions. Benennen Sie Decisions als Frage: "IsHighValue_YesNo" oder "HasContacts_YesNo". So erkennen Sie auf einen Blick, was geprüft wird.

Assignment setzt Werte auf Variablen oder Records. Hier passiert die eigentliche Arbeit: Felder befüllen, Zähler hochsetzen, Records zu Collections hinzufügen. Das letzte Element in einem Loop ist fast immer ein Assignment: col_ContactsToUpdate Add CurrentItem.

Loop durchläuft eine Collection von Records. Innerhalb des Loops arbeiten Sie mit dem CurrentItem. Dem aktuellen Datensatz. Das letzte Element im Loop sollte immer ein Assignment sein, das den bearbeiteten Record zu einer Output-Collection hinzufügt. Die Bulk-Operation kommt dann nach dem Loop. Detaillierte Loop-Optimierung finden Sie in dem aktuellen Datensatz. Das letzte Element im Loop sollte immer ein Assignment sein, das den bearbeiteten Record zu einer Output-Collection hinzufügt. Die Bulk-Operation kommt dann nach dem Loop. Detaillierte Loop-Optimierung finden Sie in Teil 3.

Create, Update, Delete Records. Die DML-Operationen. Erstellen, ändern, löschen. Platzieren Sie diese immer außerhalb von Loops, um Governor Limits zu respektieren. Bei Delete besondere Vorsicht: Testen Sie in der Sandbox, denn Löschungen lassen sich nicht per Undo rückgängig machen.

Variablen und Ressourcen sauber nutzen

Flows haben verschiedene Ressourcentypen, und die richtige Wahl spart Elemente und Komplexität:

Variablen speichern Einzelwerte (Text, Number, Date, Record, Boolean). Benennung mit Präfix: var_OpportunityStage, var_Count, rec_Contact.
Collections bündeln mehrere Records desselben Typs. Benennung: col_Contacts, col_LeadsToUpdate. Unverzichtbar für Bulk-Operationen nach Loops.
Formeln berechnen Werte dynamisch ohne zusätzliche Elemente. frm_DueDate = {!$Record.CloseDate} + 7 ersetzt ein Assignment-Element. Formeln können auch IF-Logik enthalten und damit Decisions einsparen: IF(Amount > 10000, 'High', 'Standard'). Testen Sie Formeln im Debugger. Typfehler (Text statt Date) crashen den Flow.Typfehler (Text statt Date) crashen den Flow.
Text Templates formatieren dynamische Texte mit Platzhaltern. txt_EmailBody = "Hallo {!var_FirstName}, Ihre Opportunity...". Ideal für ideal für E-Mail-Benachrichtigungen in Flows.
Konstanten speichern unveränderliche Werte. const_MaxRetries = 3 oder const_TaxRate = 0.19. In der Praxis seltener genutzt als Variablen, aber nützlich für harte Grenzwerte.

Fortgeschrittene Patterns

Wenn die Basics sitzen, machen diese Patterns den Unterschied zwischen einem funktionierenden und einem professionellen Flow.

Dynamische Org-Links mit Custom Labels

Hardcodierte URLs in Flows sind ein häufiger Fehler. Der Link https://mycompany.my.salesforce.com/001xyz funktioniert in Produktion, aber bricht in der Sandbox. Verwenden Sie stattdessen diese Formel:

LEFT({!$Api.Enterprise_Server_URL_100}, FIND('/services', {!$Api.Enterprise_Server_URL_100})) & {!$Record.Id}

$Api.Enterprise_Server_URL_100 gibt die Basis-URL der aktuellen Org zurück. LEFT und FIND schneiden alles nach "/services" ab. Das Ergebnis: In der Sandbox zeigt der Link auf https://test.my.salesforce.com/001xyz, in Produktion auf https://prod.my.salesforce.com/001xyz. Ohne manuelle Änderung nach dem Deployment.

Speichern Sie den Link in einer Formel-Variable und verwenden Sie ihn in E-Mails, Task-Beschreibungen oder Screen Flow-Feldern. So bleiben Ihre Flows deployment-sicher.

Scheduled Flows monatlich laufen lassen

Salesforce bietet für Scheduled Flows nur "Daily" und "Weekly" als Frequenz an. Für monatliche Läufe brauchen Sie einen Trick:

Erstellen Sie ein Formelfeld (Checkbox) auf dem Zielobjekt, z. B. Is_First_Of_Month__c mit der Formel DAY(TODAY()) = 1. Das Feld ist am 1. jedes Monats true.
Nutzen Sie einen Record-Triggered Flow, der bei Änderung dieses Feldes auf true startet.
Alternativ: Ein Hilfs-Objekt als "Flow Trigger", das täglich per Scheduled Flow geprüft wird und dann den eigentlichen Prozess anstößt.

Ein Kunde nutzt dieses Pattern, um am 1. jeden Monats überfällige Cases automatisch zu eskalieren. Funktioniert zuverlässig seit über einem Jahr. Für stündliche Läufe erstellen Sie mehrere tägliche Scheduled Flows mit versetzten Startzeiten (08:00, 09:00, 10:00).

Screen Flow Patterns

Screen Flows sind das Frontend-Tool für Admins. Zwei Patterns, die ich ständig einsetze:

Wizard-Pattern: Mehrere Screens hintereinander, die den User durch einen komplexen Prozess führen. Ideal für Datenerfassung mit Validierung. Nutzen Sie Abschnitte für visuelle Struktur, klare Labels ("Wählen Sie die Priorität"), und sinnvolle Defaults. Validierungsregeln direkt im Screen-Element fangen Eingabefehler ab, bevor der User zum nächsten Schritt kommt.

Data Table Pattern: Für interaktive Listen. Records anzeigen, auswählen, bearbeiten. Besonders mächtig mit der Data Table-Komponente, die ich in meinem Records anzeigen, auswählen, bearbeiten. Besonders mächtig mit der Data Table-Komponente, die ich in meinem Screen Flow Data Table-Artikel detailliert erkläre.

Testing und Versionierung

Ein Flow ohne Tests ist ein Risiko. Meine Teststrategie f��r jeden Flow:

Before/After-Vergleich. Erstellen Sie einen Test-Record vor der Aktivierung. Notieren Sie das erwartete Ergebnis. Aktivieren Sie den Flow. Erstellen Sie denselben Record. Stimmt das Ergebnis überein? Testen Sie mindestens drei Szenarien: den Normalfall, den Grenzfall (leere Daten, null-Werte, fehlende Records) und den Negativfall (Bedingungen nicht erfüllt. Der Flow darf dann nichts tun).

Debug-Modus nutzen. Der Flow Builder hat einen eingebauten Debugger. Öffnen Sie den Flow, klicken Sie auf "Debug", und durchlaufen Sie ihn Schritt für Schritt. Sie sehen jeden Variablenwert in Echtzeit. Besonders nützlich bei Decision-Elementen, wo Sie sofort erkennen, welchen Pfad der Flow genommen hat und warum. Die häufigste Überraschung: Eine Bedingung evaluiert zu besonders nützlich bei Decision-Elementen, wo Sie sofort erkennen, welchen Pfad der Flow genommen hat und warum. Die häufigste Überraschung: Eine Bedingung evaluiert zu false, weil ein Feld null statt leer ist.

⚠️

Häufiger Fehler: Conditions evaluieren zu `false`, weil ein Feld `null` statt leer ist. Im Flow-Debugger sehen Sie das sofort. Fügen Sie für kritische Decisions eine zusätzliche Bedingung `IS NULL = false` hinzu. Das macht Ihren Flow stabiler und verhindert stille Fehlläufe.

Flow-Versionen managen. Jede Änderung an einem aktiven Flow erstellt eine neue Version. Die alte bleibt erhalten. Ein eingebautes Sicherheitsnetz. Nutzen Sie das: Schreiben Sie in das Versions-Beschreibungsfeld, was Sie geändert haben. Bei einem Deployment von Sandbox zu Produktion wird nur die aktive Version übernommen. Stellen Sie sicher, dass es die richtige ist. Mehr dazu in meinem Artikel zur ein eingebautes Sicherheitsnetz. Nutzen Sie das: Schreiben Sie in das Versions-Beschreibungsfeld, was Sie geändert haben. Bei einem Deployment von Sandbox zu Produktion wird nur die aktive Version übernommen. Stellen Sie sicher, dass es die richtige ist. Mehr dazu in meinem Artikel zur stellen Sie sicher, dass es die richtige ist. Mehr dazu in meinem Artikel zur Deployment-Nachbereitung.

Diese Serie: Teil 1: Flow-Leitfaden | Teil 2: Flows aufbauen (dieser Artikel) | Teil 3: Best Practices

Häufige Fragen

Wie gehe ich den Aufbau eines neuen Salesforce Flows am besten an?

Zuerst den Use Case auf Papier oder in einem Diagramm durchdenken: Trigger, Bedingungen, Aktionen, Ausnahmen. Dann den Flow in einer Sandbox aufbauen, mit Debug-Mode testen und erst nach erfolgreichem Test in Production deployen.

Was ist Solution Design bei Salesforce Flows?

Solution Design bedeutet, vor dem ersten Klick im Flow Builder genau zu definieren: welche Objekte betroffen sind, welche Bedingungen gelten, in welcher Reihenfolge Aktionen ausgefuhrt werden und wie Fehler behandelt werden. Das spart Stunden an Debugging.

Welche Flow-Typen gibt es und wann nutze ich welchen?

Record-Triggered Flows für automatische Aktionen bei Datensatz-Änderungen, Screen Flows für geführte Nutzer-Interaktionen, Scheduled Flows für zeitbasierte Aktionen und Autolaunched Flows für den Aufruf aus anderen Flows oder Apex. Record-Triggered und Screen Flows decken 90% der Anwendungsfälle ab.

Wie dokumentiere ich einen Salesforce Flow für spätere Wartung?

Nutzen Sie den Beschreibungstext im Flow und in jedem Element konsequent. Benennen Sie Elemente sprechend (nicht "Element_1"), und pflegen Sie eine kurze technische Dokumentation außerhalb von Salesforce für komplexe Flows.

Wenn Sie Unterstützung beim Aufbau komplexer Flows brauchen. Ob Screen Flow Wizards, Subflow-Architekturen oder die Integration mit Apex. Stehe ich Ihnen zur Seite. Ich entwickle und optimiere Flows seit Jahren in dutzenden Salesforce-Orgs, und ich weiß, welche Patterns funktionieren und welche sich als Sackgasse entpuppen.