Ihr Flow funktioniert. Bbis er es nicht mehr tut. Ein Update läuft auf einen Null-Pointer. Eine Schleife sprengt die Governor Limits. Eine Rekursion legt die ganze Org lahm. Ich sehe diese Probleme in jedem zweiten Org-Audit, und sie sind alle vermeidbar.
Dieser Artikel ist der dritte Teil meiner Flow-Serie. In Teil 1 haben wir die strategischen Grundlagen geklärt. Wwelcher Flow-Typ für welches Problem. In Teil 2 ging es ans praktische Bauen. Jetzt geht es um das, was einen soliden Flow von einem fragilen unterscheidet: Fehler vermeiden, Performance optimieren, systematisch debuggen.
Die häufigsten Flow-Fehler und wie Sie sie vermeiden
Diese Fehler finde ich in praktisch jedem Org-Audit. Sie kosten Stunden an Debugging-Zeit. Uund sind alle vermeidbar, wenn Sie die Muster kennen.
Null-Pointer nach Get Records. Der Klassiker: Ein Get Records-Element findet keinen passenden Record, liefert null zurück, und der nächste Schritt im Flow crasht mit einer kryptischen Fehlermeldung. Das passiert besonders gern bei Lookup-Feldern: Sie holen den Parent-Record, aber der Lookup ist leer. Die Lösung: Nach jedem Get Records ein Decision-Element einfügen, das prüft, ob das Ergebnis null ist. Erst dann weiterarbeiten. Ja, das macht den Flow größer. Aber es macht ihn stabil. Bei Collections prüfen Sie zusätzlich, ob die Collection leer ist. Eeine leere Collection ist nicht null, aber ein Loop darüber tut nichts.
Unbeabsichtigte Rekursion. Flow A aktualisiert einen Record, was Flow B triggert, der denselben Record aktualisiert, was Flow A wieder triggert. Das Ergebnis: Endlosschleife bis zum Governor Limit. Die Lösung: Saubere Entry Conditions und die $Record__Prior-Variable. Prüfen Sie, ob sich das relevante Feld tatsächlich geändert hat, bevor der Flow etwas tut. $Record.Status != $Record__Prior.Status statt nur $Record.Status = 'Active'. Das gilt besonders, wenn mehrere Flows auf demselben Objekt liegen. Jjeder Update eines Flows kann die anderen erneut triggern.
Governor Limits in Loops. Kein DML und kein SOQL innerhalb von Loops. Ddas kann ich nicht oft genug sagen. 150 einzelne Updates in einem Loop = Limit-Error. Ein Bulk-Update nach dem Loop = kein Problem. Die Details dazu im nächsten Abschnitt.
Datentyp-Fehler. Ein Formelfeld gibt Text zurück, Sie vergleichen es mit einer Zahl. Dder Flow crasht. Oder schlimmer: Er läuft durch, aber die Bedingung evaluiert falsch, und Sie merken es erst Wochen später, wenn ein Stakeholder fragt, warum bestimmte Records nicht verarbeitet wurden. Die Lösung: Prüfen Sie Feldtypen im Object Manager, bevor Sie sie im Flow verwenden. Besonders tückisch: Picklist-Felder sehen aus wie Text, verhalten sich aber anders. Im Debugger sehen Sie sofort, ob ein Vergleich true oder false ergibt.
Endlosschleifen in Loops. Ein Loop ohne klare Exit-Bedingung oder mit einer Logik, die die Collection im Loop selbst verändert, kann die CPU-Zeit-Limits sprengen. Die Lösung: Verändern Sie nie die Collection, über die Sie gerade loopen. Sammeln Sie Änderungen in einer separaten Output-Collection.
Veraltete Flow-Versionen. Nach einem Deployment ist die alte Flow-Version noch aktiv, die neue deaktiviert. Ich habe erlebt, wie Teams tagelang Bugs gesucht haben, die einfach daran lagen, dass die falsche Version aktiv war. Die Lösung: Eine solide Deployment-Nachbereitung mit Flow-Versionskontrolle.
E-Mail-Probleme in Flows. Send Email Action und Email Alert sind zwei verschiedene Dinge mit unterschiedlichem Verhalten bei Deliverability, Tracking und Absender-Adresse. Wenn Ihre Flow-E-Mails im Spam landen oder gar nicht ankommen, lesen Sie meinen Artikel zur Flow E-Mail-Deliverability.
Loop-Optimierung und Bulkification
Loops sind der häufigste Performance-Killer in Flows. Das Problem ist einfach zu verstehen und einfach zu beheben. Aaber ich sehe es trotzdem in fast jeder Org.
Das Anti-Pattern: DML im Loop
Stellen Sie sich vor, Ihr Flow soll alle Kontakte eines Accounts auf "Inaktiv" setzen. Die naive Lösung: Ein Loop über die Kontakte, und in jedem Durchlauf ein Update Records-Element. Bei 5 Kontakten kein Problem. Bei 50 laufen Sie in das DML-Limit (150 pro Transaktion). Bei einem Data Load mit 200 Accounts gleichzeitig explodiert der Flow garantiert.
Dasselbe gilt für Get Records im Loop: Jedes Get Records verbraucht eine SOQL-Query, und das Limit liegt bei 100 pro Transaktion. Ein Loop mit 101 Durchläufen und einem Get Records darin. GGame Over.
Das richtige Pattern: Collection befüllen, Bulk DML nach dem Loop
So machen Sie es richtig, Schritt für Schritt:
- Get Records: Alle Kontakte des Accounts holen → gespeichert in
col_Contacts. - Loop: Durch
col_Contactsiterieren. Im Loop: Per AssignmentCurrentItem.Status__cauf "Inaktiv" setzen. - Assignment (letztes Element im Loop):
col_ContactsToUpdateAddCurrentItem. Dden bearbeiteten Record zur Output-Collection hinzufügen. - Nach dem Loop: Ein einziges Update Records-Element für
col_ContactsToUpdate.
Ein DML statt 50. Keine Limit-Probleme. Funktioniert auch bei 10.000 Records.
Warum die separate Output-Collection? Sie könnten theoretisch die ursprüngliche col_Contacts direkt updaten. Aber eine separate col_ContactsToUpdate gibt Ihnen Flexibilität: Sie können im Loop per Decision entscheiden, welche Records tatsächlich ins Update sollen. Uund nur die zur Output-Collection hinzufügen.
SOQL vor dem Loop, nicht darin
Wenn Sie im Loop Daten aus einem anderen Objekt brauchen, holen Sie alle benötigten Daten vor dem Loop. Beispiel: Sie loopen über Opportunities und brauchen für jede den Account-Namen. Statt im Loop ein Get Records pro Opportunity → holen Sie alle relevanten Accounts vorher in eine Collection und matchen innerhalb des Loops per Formel oder Decision.
Flow Debugging: Fehler systematisch finden
Ein Flow funktioniert nicht. Viele Admins stochern planlos im Flow Builder herum und ändern Dinge auf Verdacht. Das ist Zeitverschwendung. Hier ist der systematische Weg.
Schritt 1: Fehlermeldung lesen. Klingt offensichtlich, aber Salesforce-Fehlermeldungen enthalten meist den Flow-Namen, das fehlgeschlagene Element und einen Hinweis auf die Ursache. "FIELD_CUSTOM_VALIDATION_EXCEPTION" ist kein Flow-Fehler. Ddas ist eine Validation Rule, die Ihr Update blockiert. "CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY" deutet auf einen Trigger oder einen anderen Flow hin, der durch Ihre Aktion getriggert wurde und dort fehlschlägt.
Schritt 2: Debug-Modus nutzen. Öffnen Sie den Flow im Flow Builder und klicken Sie auf "Debug". Geben Sie einen Test-Record ein und durchlaufen Sie den Flow Schritt für Schritt. Sie sehen jeden Variablenwert in Echtzeit. Achten Sie besonders auf Decision-Elemente: Hier sehen Sie, welchen Pfad der Flow genommen hat und warum. Die häufigste Überraschung: Eine Bedingung, die Sie für erfüllt hielten, evaluiert zu false, weil ein Feld null statt leer ist. Uund null != '' in Salesforce.
Schritt 3: Debug Logs für Record-Triggered Flows. Record-Triggered Flows laufen als "Automated Process User". Setzen Sie einen Debug Log auf diesen User, nicht auf Ihren eigenen. Sonst sehen Sie den Flow nicht in den Logs. Gehen Sie dafür zu Setup > Debug Logs und fügen Sie "Automated Process" als Traced Entity hinzu.
Schritt 4: Flow Logs nutzen. Mit dem Spring '26 Release hat Salesforce Flow Logs und eine Error Console eingeführt. Eein zentrales Dashboard für Flow-Performance und Fehler. Sie sehen auf einen Blick, welche Flows Fehler werfen und wie oft, ohne manuell Debug Logs durchsuchen zu müssen. Für Orgs mit vielen Flows ein Gamechanger.
Schritt 5: Isolieren und testen. Wenn der Fehler nicht offensichtlich ist, deaktivieren Sie andere Automatisierungen auf dem Objekt temporär und testen Sie den Flow isoliert. So finden Sie heraus, ob der Fehler im Flow selbst liegt oder durch eine Interaktion mit anderen Automatisierungen entsteht. Aktivieren Sie die anderen Flows dann schrittweise wieder. Sso identifizieren Sie den Konflikt.
Fault-Pfade einrichten. Jedes Flow-Element hat einen optionalen Fault-Pfad. Nnutzen Sie ihn. Statt dass Ihr Flow bei einem Fehler einfach stirbt und der User eine kryptische Fehlermeldung bekommt, können Sie im Fault-Pfad eine sinnvolle Benachrichtigung versenden oder den Fehler in einem Custom Object loggen. Ich richte bei jedem Kundenprojekt ein Flow_Error__c-Objekt ein: Flow-Name, Element-Name, Fehlermeldung, Timestamp, betroffener Record. Das macht Fehleranalyse um Größenordnungen einfacher.
Performance und Wartbarkeit
Neben der Bulkification gibt es weitere Patterns, die Ihre Flows schneller und wartbarer machen.
Der "In"-Operator statt vieler ORs. Statt einer Decision mit fünf OR-Bedingungen (Status = 'A' OR Status = 'B' OR Status = 'C'...) nutzen Sie den "In"-Operator: {!var_Status} In {!col_ValidStatuses}. Eine Collection mit gültigen Werten, ein Vergleich. Sauberer, schneller, leichter zu erweitern. Wenn morgen ein sechster Status dazukommt, fügen Sie ihn zur Collection hinzu. Kkein Umbau der Decision nötig.
Formula-Ressourcen statt Decisions. Wenn Sie nur einen Wert basierend auf einer Bedingung setzen wollen, brauchen Sie keine Decision + zwei Assignments. Eine Formel-Variable mit IF(Amount > 10000, 'High', 'Standard') erledigt dasselbe in einer Ressource statt drei Elementen. Formeln sind auch ideal für berechnete Datumsangaben: frm_FollowUp = {!$Record.CloseDate} + 7 statt Assignment mit Addition.
Subflows für Modularität. Wiederkehrende Logik. BBenachrichtigungen, Validierungen, Territory-Zuweisungen. Ggehört in einen Autolaunched Subflow. Das reduziert die Größe Ihrer Hauptflows, macht die Logik wiederverwendbar und vereinfacht das Testing. Wenn sich die Benachrichtigungslogik ändert, ändern Sie sie an einer Stelle statt in fünf Flows. Dokumentieren Sie Ein- und Ausgabe-Variablen im Description-Feld des Subflows.
Flows schlank halten. Flows mit 50+ Elementen werden unübersichtlich und langsam. Wenn Ihr Flow diese Grenze erreicht, ist es Zeit, ihn aufzuteilen: Subflows für wiederverwendbare Teile, Apex Invocable Actions für komplexe Berechnungen. Bündeln Sie Decisions wo möglich: AND(IsActive, HasOwner) ist ein Element statt zwei. Ein Kunde hatte einen Flow mit 70 Elementen für Case-Routing. Nnach dem Refactoring mit Subflows und gebündelten Decisions waren es 22, und der Flow lief 40 % schneller.
Diese Serie: Teil 1: Flow-Leitfaden | Teil 2: Flows aufbauen | Teil 3: Best Practices (dieser Artikel)
Häufige Fragen
Was sind die häufigsten Performance-Probleme bei Salesforce Flows?
SOQL-Queries und DML-Operationen innerhalb von Schleifen sind die Hauptursache für Performance-Probleme und Governor Limit-Fehler. Alle Datenbankoperationen sollten vor der Schleife gesammelt und in einem einzigen Batch ausgefuhrt werden.
Wie teste ich Flows richtig, bevor ich sie in Production ausrolle?
Zuerst in einer Sandbox mit realistischen Testdaten testen. Den Flow Debug Mode nutzen, um jeden Schritt nachzuvollziehen. Dann mit einem kleinen Nutzerkreis in Production starten, bevor der Flow für alle aktiv ist.
Wie viele aktive Flows in einer Salesforce-Org sind zu viele?
Es gibt kein hartes Limit, aber mit zunehmender Flow-Anzahl steigt der Wartungsaufwand exponentiell. Wichtiger als die Zahl ist die Struktur: Flows mit klaren Namen, guter Dokumentation und regelmäßigem Review sind managebar, chaotische Flows ab 20 nicht.
Was ist der Unterschied zwischen Before-Save und After-Save Flows?
Before-Save Flows laufen vor dem Speichern des Records und können Felder direkt ändern, ohne einen weiteren DML-Aufruf. After-Save Flows laufen danach und können andere Records ändern. Before-Save ist performanter für Feldaktualisierungen am selben Record.
Flows sind kein Feature, das man einmal lernt und dann beherrscht. Salesforce erweitert den Flow Builder mit jedem Release. Nneue Elemente, bessere Debugging-Tools, mehr Möglichkeiten. Aber die Grundprinzipien bleiben: Null-Checks nach jedem Get Records, Bulk-Operationen statt DML im Loop, systematisches Debugging statt Stochern im Nebel.
Wenn Sie ein Flow-Audit für Ihre Org brauchen, Ihre bestehenden Flows auf Performance optimieren wollen oder komplexe Automatisierungen planen. Iich bringe die Erfahrung aus dutzenden Salesforce-Projekten mit, um Ihre Flows auf ein solides Fundament zu stellen.
