Auf dem Case-Objekt liegen zwölf record-triggered Flows, zwei davon schalten sich gegenseitig um, und der dreizehnte steht schon im Ticket. Niemand im Team kann in unter einer Stunde aufschreiben, was beim Speichern eines Case tatsächlich passiert. Die Frage ist nicht mehr, ob Sie den nächsten Flow bauen können, sondern ob Sie ihn noch verantworten können.
Dieser Artikel zieht eine Grenze: ab wann ein weiterer Flow teurer ist als die Auslagerung, wie Sie das an Ihrem Objekt in einer halben Stunde selbst prüfen, und was die Auslagerung kostet. Sie kostet etwas, und das gehört vor die Entscheidung, nicht danach.
Die Grenze ist keine Zahl von Flows, sondern eine Frage, die niemand beantworten kann
Es gibt keinen Schwellenwert der Art: ab acht Flows auslagern. Es gibt Orgs mit zwanzig Flows auf dem Case-Objekt, die sauber laufen, und Orgs mit dreien, bei denen jede Änderung ein Risiko ist. Der Unterschied liegt nicht in der Menge, sondern in der Erklärbarkeit.
Die Grenze ist dort erreicht, wo sich die Frage Was passiert beim Speichern dieses Datensatzes? nicht mehr aus dem System beantworten lässt, sondern nur noch durch Ausprobieren in einer Sandbox. Ab diesem Punkt ist jede Änderung eine Vermutung, und das Testen kostet mehr als das Bauen. Das ist der Moment, in dem ein weiterer Flow teurer wird als die Auslagerung.
Die Grenze ist erreicht, wenn Ihre Org nur noch durch Ausprobieren erklärbar ist.
Zwei Dinge machen eine Org unerklärbar, und beide haben nichts mit der Anzahl zu tun. Erstens die Reihenfolge: record-triggered Flows ohne gesetzte Trigger Order laufen in nicht garantierter Reihenfolge, und diese Reihenfolge kann sich nach einem Deployment ändern. Zwei Flows, die beide den Status setzen, ergeben dann mal das eine und mal das andere Ergebnis. Zweitens die implizite Kopplung: Flow A setzt ein Feld, auf dessen Wert Flow B als Einstiegsbedingung prüft, ohne dass das irgendwo dokumentiert wäre. Beides gehört zu den häufigsten Automatisierungsfehlern in Salesforce und beides lässt sich reparieren, ohne etwas aus der Org zu nehmen.
Drei Fragen entscheiden schneller als jede Analyse
- Können Sie in 15 Minuten die vollständige Liste aufschreiben? Alles, was beim Speichern läuft: record-triggered Flows vor und nach dem Speichern, Apex Trigger, Validation Rules, Assignment Rules, Auto-Response Rules, Escalation Rules, Process-Builder-Reste, Roll-up Summaries auf dem übergeordneten Datensatz. Wenn diese Liste niemand zusammenbekommt, ist Ihre Logik nicht zu groß, sondern unsichtbar.
- Ändert ein Eingriff in Flow A das Ergebnis von Flow B, ohne dass das in Flow A steht? Dann ist die Kopplung implizit. Implizite Kopplung lässt sich in Salesforce nicht dokumentieren, nur nachbauen, und sie ist der Grund, warum Änderungen an einer Stelle an einer anderen etwas kaputt machen.
- Braucht die Logik etwas, das die Transaktion nicht hat? Eine Antwort aus einem anderen System, einen HTTP-Callout, mehr als zehn Sekunden Rechenzeit, eine Wartezeit von Tagen. Dann liegt die Logik bereits außerhalb der Transaktion, und Sie verstecken das nur in einem asynchronen Pfad.
Frage drei entscheidet allein. Ein einziges Ja dort bedeutet: die Auslagerung ist keine Option mehr, sondern bereits Realität, nur an einer schlecht gewählten Stelle. Bei Frage eins und zwei zählt die Kombination. Nur Frage eins mit Ja heißt: dokumentieren und aufräumen, nicht auslagern.
Beim Speichern läuft eine feste Reihenfolge, und Ihre Flows stehen an zwei Stellen darin
Salesforce arbeitet beim Speichern eines Datensatzes eine festgelegte Reihenfolge ab, die Order of Execution. Verkürzt auf das, was für diese Entscheidung zählt:
- before-save Flows und before-Trigger
- Validation Rules
- Speichern in die Datenbank, noch ohne Commit
- after-save Flows und after-Trigger
- Assignment Rules, Auto-Response Rules, Workflow Rules, Escalation Rules
- Roll-up Summaries auf dem übergeordneten Datensatz, der dadurch dieselbe Reihenfolge noch einmal komplett durchläuft
- Commit
Daraus folgt der erste Hebel, und er hat nichts mit Auslagern zu tun. Ein after-save Flow, der ein Feld auf demselben Datensatz setzt, löst eine zweite Speicheroperation aus. Ein before-save Flow setzt denselben Wert ohne zweites Speichern. Salesforce beziffert den Unterschied auf etwa das Zehnfache an Ausführungszeit. Wer zwölf Flows auf einem Objekt hat und die Hälfte davon sind reine Feldupdates nach dem Speichern, gewinnt mehr durch das Umhängen als durch jede Architekturentscheidung. Welche Automatisierung überhaupt die richtige ist, klärt der Artikel zu Flow, Validation Rule oder Approval Process.
Der zweite Punkt ist der Roll-up Summary. Er startet die vollständige Reihenfolge auf dem übergeordneten Datensatz erneut, inklusive aller Flows, die dort liegen. Bei Account, Opportunity und Case mit jeweils eigenen Automatisierungen ist das der Ort, an dem Rechenzeit verschwindet, ohne dass jemand einen Flow dafür verantwortlich macht.
Zwei Dinge sprengen die Transaktion: Rechenzeit und Warten auf ein anderes System
Alles, was beim Speichern passiert, läuft in einer Transaktion und teilt sich deren Grenzen. Die wichtigsten Werte für den synchronen Fall, asynchron in Klammern:
- 10 Sekunden Rechenzeit (60 Sekunden)
- 100 SOQL-Abfragen (200)
- 150 DML-Anweisungen und 10.000 verarbeitete Datensätze
- 6 MB Heap (12 MB)
- 100 Callouts, zusammen höchstens 120 Sekunden
Diese Grenzen gelten auch dann, wenn in Ihrer Org keine Zeile Apex liegt. Der Fehler heißt trotzdem Apex CPU time limit exceeded, weil Flows dieselbe Laufzeitumgebung nutzen.
Ein Beispiel, das sich nachrechnen lässt. Sie importieren 5.000 Cases über den Data Loader. Der verarbeitet in Paketen zu 200 Datensätzen, jedes Paket ist eine Transaktion. Auf dem Case liegen zwölf after-save Flows, einer davon holt innerhalb einer Schleife über die Case-Datensätze per Get Records das passende Entitlement. Eine Abfrage pro Datensatz, 200 Datensätze pro Transaktion, Limit 100. Der Import bricht ab, bevor die Hälfte des ersten Pakets durch ist. Derselbe Flow läuft im Tagesgeschäft bei einem einzelnen Case jahrelang unauffällig.
Der zweite Fall ist gravierender. Sobald ein Flow auf die Antwort eines anderen Systems wartet, hängt die Speicheraktion des Anwenders an dessen Antwortzeit. Wird das andere System langsam, wird Ihr Case-Speichern langsam. Fällt es aus, schlägt das Speichern fehl. Das ist keine Automatisierung mehr, das ist eine Abhängigkeit, die Sie im falschen Moment eingehen.
Drin bleibt alles, was der Anwender sofort sieht oder was die Daten schützt
Für diese Logik ist die Transaktionsgrenze kein Hindernis, sondern die eigentliche Funktion:
- Validation Rules und Pflichtfeldlogik. Eine Prüfung, die erst nach dem Speichern greift, ist keine Prüfung. Sie ist ein Bericht über einen Fehler, der schon in der Datenbank steht.
- Feldwerte, die sich aus dem Datensatz selbst ergeben. Statusableitungen, Normalisierungen, Kennzeichen. Gehören in einen before-save Flow und sonst nirgendwohin.
- Sichtbarkeit und Freigaben. Sharing-Entscheidungen, die von Feldwerten abhängen, müssen im selben Moment fallen wie das Speichern.
- Alles, was der Anwender als direkte Reaktion erwartet. Wenn nach dem Speichern sofort etwas anders aussehen soll, muss es in der Transaktion passieren.
Was das kostet: diese Logik bleibt im Wartungsbudget der Org, mit allem, was dazugehört. Benennung, Dokumentation, Trigger Order, Testabdeckung. Der Preis ist hier richtig bezahlt. Wie man diese Logik übersichtlich hält, steht in den Flow Best Practices für Admins.
Raus gehört alles, was auf ein zweites System wartet oder fachlich woanders hingehört
- Fachlogik eines anderen Systems. Preisfindung, Bonitätsprüfung, Verfügbarkeit, Fakturierung. In Salesforce nachgebaut haben Sie dieselbe Regel zweimal, und die zweite Kopie ist immer die veraltete.
- Jede Logik mit Callout. Wenn ein anderes System antworten muss, gehört der Schritt aus der Speichertransaktion heraus, egal wie schnell das andere System heute ist.
- Massenverarbeitung. Nächtliche Neuberechnungen, Datenabgleiche, Bereinigungen. Das sind Batch-Aufgaben, und Batch-Aufgaben gehören nicht an einen Speichervorgang.
- Orchestrierung über Tage mit vielen Zuständen. Technisch geht das mit Scheduled Paths. Beobachtbar ist es kaum: die einzige Sicht darauf ist Setup, Paused and Failed Flow Interviews, und dort steht keine fachliche Begründung, warum ein Vorgang hängt.
Was die Auslagerung kostet und was sie bricht
Sie tauschen eine unübersichtliche Logik gegen eine zweite Systemgrenze. Dieser Tausch hat einen Preis, und er fällt dauerhaft an:
- Kein gemeinsamer Rollback mehr. Salesforce committet, der externe Schritt fällt aus, und der Datensatz steht in einem Zustand, den keine der beiden Seiten allein reparieren kann. Sie brauchen Idempotenz und einen Wiederholungsweg. Diese Arbeit hatten Sie innerhalb der Org nicht.
- Die Fehlerbehandlung verlässt Salesforce. Heute bekommt der Flow-Eigentümer eine Fehler-E-Mail und die Sache ist sichtbar. Danach brauchen Sie Monitoring, eine Alarmierung und jemanden, der darauf reagiert.
- Ein Betriebsthema mehr. Ein Connected App, ein Integrationsnutzer, Zertifikate mit Ablaufdatum, zwei Release-Zyklen, die aufeinander warten. Nichts davon ist schwierig, alles davon ist dauerhaft.
- Der Ereignisbus vergisst. Platform Events und Change Data Capture liegen 72 Stunden im Bus. Wer länger offline ist, hat die Ereignisse verloren und braucht einen vollständigen Abgleich, nicht nur einen Replay. Outbound Messages wiederholen 24 Stunden lang, danach ist die Nachricht weg.
Deshalb ist die Empfehlung keine pauschale. Wenn keine der drei Fragen oben ein klares Ja ergibt, zahlen Sie diesen Preis ohne Gegenwert. Dann ist Aufräumen innerhalb der Org die richtige und deutlich billigere Antwort.
Ein Weg, der funktioniert: Ereignis raus, Ergebnis zurück ins Feld
Wenn die Entscheidung für die Auslagerung gefallen ist, gibt es viele Varianten. Diese hier ist die, die sich am zuverlässigsten betreiben lässt:
- Der Flow in der Org schreibt ein Platform Event und sonst nichts. Kein Callout, keine Wartezeit, keine Fremdlogik in der Speichertransaktion.
- Ein externer Dienst abonniert das Event, rechnet oder fragt an, was er braucht, und schreibt das Ergebnis über die API in eigene Felder auf dem Datensatz zurück.
- Der Verarbeitungsstatus steht als Feld auf dem Datensatz, nicht nur in einem Log: offen, verarbeitet, fehlgeschlagen, mit Zeitstempel. Ein Report darauf ist Ihr Monitoring, und er ist in Salesforce sichtbar statt in einem fremden System.
- Der externe Dienst ist idempotent. Dieselbe Replay-ID zweimal verarbeitet ergibt dasselbe Ergebnis.
Was das kostet: einen Dienst, der dauerhaft läuft und den Bus abonniert. Ein Skript, das stündlich abfragt, ist billiger, verliert aber die Ereignisreihenfolge und braucht einen eigenen Abgleichlauf. Was es bricht: die Logik ist nicht mehr synchron. Alles, was Anwender bisher unmittelbar nach dem Speichern gesehen haben, sehen sie jetzt einige Sekunden später. Das muss erklärt werden, sonst gilt das neue System als kaputt.
Die Reihenfolge, in der Sie vorgehen
- Bild machen. Flow Trigger Explorer, Apex Trigger, Validation Rules, Roll-ups. Ein halber Tag pro Objekt. Ohne dieses Bild ist jede weitere Entscheidung geraten.
- Feldupdates von after-save nach before-save ziehen. Billigster Schritt mit dem größten Effekt, ohne Architekturwechsel.
- Trigger Order auf allen aktiven record-triggered Flows setzen. Ab diesem Moment ist die Reihenfolge festgelegt statt zufällig.
- Erst danach entscheiden, was die Org verlässt. Nach den Schritten davor bleiben meist zwei bis drei Kandidaten übrig, nicht zwölf.
Was die Schritte zwei und drei kosten: Testaufwand, und zwar den vollen. Was sie brechen: Flows, die sich bisher auf eine Reihenfolge verlassen haben, die nie festgelegt war, ändern ihr Verhalten. Genau deshalb passiert das vor der Auslagerung und nicht danach. Wer beides gleichzeitig macht, kann hinterher nicht mehr sagen, welche Änderung welchen Effekt hatte.
Häufige Fragen
Ab wie vielen Flows pro Objekt wird es kritisch?
Es gibt keine Zahl. Zwanzig benannte, nach Trigger Order sortierte Flows mit klaren Einstiegsbedingungen sind beherrschbar. Drei Flows, die sich gegenseitig auslösen und deren Reihenfolge niemand festgelegt hat, sind es nicht. Entscheidend ist, ob jemand die Wirkung einer Änderung vorhersagen kann.
Reicht es nicht, alle Flows zu einem einzigen zusammenzufassen?
Oft ja, und es ist der deutlich billigere Schritt. Ein Flow pro Objekt und Auslösepunkt, der Unterflows in definierter Reihenfolge aufruft, macht die Reihenfolge explizit und die Wirkung nachvollziehbar. Die Auslagerung lohnt sich erst, wenn die Logik etwas braucht, das die Transaktion nicht hergibt.
Löst Apex statt Flow das Problem?
Es verschiebt es. Apex unterliegt denselben Governor Limits und derselben Order of Execution. Der echte Vorteil ist die Testbarkeit und die Versionierung im Repository. Das ist ein gutes Argument für Apex, aber kein Argument für die Auslagerung.
Was kostet die Auslagerung im laufenden Betrieb?
Der dauerhafte Posten ist nicht die Entwicklung, sondern die Bereitschaft. Jemand muss sehen, wenn der externe Schritt ausfällt, und reagieren, bevor Datensätze in einem falschen Zustand stehen bleiben. Wer diese Rolle nicht besetzen kann, sollte die Logik in der Org lassen und dort aufräumen.
Woran merke ich, dass ich zu lange gewartet habe?
Wenn Änderungen nur noch in einer Sandbox mit Produktionsdaten getestet werden können, weil niemand die Wirkung vorhersagen kann. Und wenn die Antwort auf die Frage, was beim Speichern passiert, mit den Worten beginnt: das müsste ich nachsehen.
Ob Logik in Ihrer Org bleibt oder herausgehört, entscheidet sich an Ihrem Objekt, nicht an einer Regel aus einem Artikel. Bringen Sie in ein kostenloses 30-Minuten-Erstgespräch das Objekt mit, an dem Sie hängen, und die Liste der Flows, die darauf liegen. Ich sage Ihnen, welche der drei Fragen bei Ihnen Ja ergibt und welcher Schritt der billigste ist. Wenn danach ein vollständiges Bild der Org nötig ist, ist der Salesforce Health Check der zweite Schritt: 4.500 € netto, 3 Personentage, Ergebnis zehn Werktage nach Kick-off, bei einer Umsetzung voll anrechenbar.
