Wenn Sie gerade noch Workflow Rules oder den Process Builder in Ihrer Salesforce-Org aktiv haben: Der End-of-Support-Termin ist verstrichen. Seit dem 31. Dezember 2025 ist Salesforce nicht mehr verpflichtet, diese Tools zu warten, Bugs zu beheben oder Support dafür zu leisten. Ihre Automatisierungen laufen noch. Aber wenn etwas schief geht, sind Sie auf sich allein gestellt.
Das ist kein theoretisches Risiko. Ich habe in Org-Audits 2026 bereits erste Fälle gesehen, wo Workflow Rules stillschweigend fehlerhafte Ergebnisse lieferten. Ohne Fehlermeldung, ohne Salesforce-Support, der hilft. Die Migration war längst überfällig.
Was "End of Support" konkret bedeutet
Viele Admins haben die Ankündigung registriert, aber den Unterschied zwischen "End of Support" und "Abschaltung" nicht vollständig eingeordnet. Hier die klaren Fakten:
- Seit Spring '25 (Frühjahr 2025): Keine neuen Workflow Rules oder Process Builder-Prozesse erstellen. Bestehende konnten noch bearbeitet werden.
- Seit 31. Dezember 2025: End of Support. Salesforce liefert keine Bug-Fixes mehr, keinen Support bei Problemen, keine Sicherheits-Patches.
- Bestehende Automatisierungen laufen weiter. Salesforce hat keine Abschaltung der Ausführung angekündigt. Aber "läuft noch" ist nicht dasselbe wie "wird unterstützt".
- Keine Weiterentwicklung mehr. Features, die in Flows längst Standard sind. Besseres Debugging, Flow Logs, Error Console. Gibt es für Process Builder nicht und wird es nie geben.
Das Szenario, das ich Kunden erkläre: Stellen Sie sich vor, Ihre Workflow Rule, die täglich 500 Leads qualifiziert, liefert ab einem Salesforce-Update plötzlich falsche Ergebnisse. Sie öffnen ein Support-Ticket. Antwort: "Dieses Tool wird nicht mehr unterstützt." Sie stehen allein vor einem System, das Sie nicht selbst debuggen können. Weil Process Builder keine vernünftigen Debugging-Tools hatte.
Warum Flows längst der richtige Standard sind
Flows gibt es nicht erst seit gestern. Salesforce hat den Flow Builder seit Jahren konsequent ausgebaut. Und die Lücken zum Process Builder sind längst geschlossen. Wer heute noch auf den Process Builder wartet, wartet auf nichts.
Was Flows besser können:
- Vollständiges Debugging. Debug-Modus mit Schritt-für-Schritt-Ausführung, Variablenwerte in Echtzeit, und seit Spring '26 eine zentrale Flow-Error-Console. Process Builder konnte nichts davon.
- Scheduled Paths. Zeitgesteuerte Aktionen direkt im Record-Triggered Flow, ohne separaten Workflow. Flexibler und im selben Kontext debuggbar.
- Screen Flows. Interaktive User-Flows. Im Process Builder schlicht nicht möglich.
- Subflows und Modularität. Wiederverwendbare Logik als Autolaunched Flow, aufgerufen aus beliebig vielen anderen Flows.
- Before-Save Flows. Feldwerte setzen ohne DML-Operation. Performanter, weniger Governor Limits.
- Bulkification. Collections, Loop-Optimierung, Bulk-DML. Die Best Practices, die im Process Builder nicht möglich waren.
Die zwei bekannten Edge Cases
Flows decken praktisch alle Anwendungsfälle des Process Builders ab. Mit zwei Ausnahmen, die in der Praxis selten auftreten, aber bekannt sein sollten.
1. "Evaluate Next Criteria". Mehrere unabhängige Kriteriengruppen
Im Process Builder konnte ein einziger Prozess mehrere Kriteriengruppen haben, die nacheinander und unabhängig voneinander auswerteten. Kriteriengruppe 1 löste ihre Aktionen aus, dann evaluierte Kriteriengruppe 2 separat. Alles in einem einzigen Prozess-Trigger.
In Flows ist ein Decision-Element ein exklusiver Pfad: der Flow geht einen Ausgang entlang und hält dann an. Es gibt kein natives "Evaluate Next".
Lösung: Decision-Elemente in Serie schalten. Nach jedem Outcome-Pfad den Flow zurück auf einen gemeinsamen Pfad führen, der dann zum nächsten Decision-Element weitergeht. Etwas mehr Klickarbeit als "Evaluate Next", aber vollständig abbildbar. Alternativ: Wenn die Kriteriengruppen wirklich unabhängig sind, als getrennte Flows mit derselben Entry Condition strukturieren.
2. Invocable Apex mit Map- und Set-Typen
Process Builder war etwas toleranter bei Invocable Apex-Methoden, die komplexe Datentypen zurückgaben. Insbesondere Map<String, Object> oder Set<String>. Flow unterstützt diese Typen nativ nicht als Variablentypen.
Lösung: Die Invocable-Methode wrappen. Statt Map<String, String> zurückzugeben, eine Apex-Klasse mit @InvocableVariable-Feldern definieren. Also eine einfache Wrapper-Klasse, deren Felder nur Flow-kompatible Typen sind (String, Integer, Boolean, SObject, List davon). Das erfordert eine kleine Anpassung der Apex-Klasse, ist aber kein großer Aufwand. Ein Entwickler braucht dafür in der Regel weniger als eine Stunde.
Beide Edge Cases treffen auf weniger als 5 % der Org-Automatisierungen, die ich in der Praxis sehe. Kein Grund, die Migration aufzuschieben.
Schritt 1: Bestandsaufnahme
Bevor Sie anfangen, brauchen Sie ein klares Bild davon, was in Ihrer Org läuft. Das ist einfacher als es klingt.
Workflow Rules: Setup → Quick Find → "Workflow Rules". Filtern nach Objekt, Status (aktiv/inaktiv), und prüfen Sie die Aktionstypen. Einfache Field Updates und E-Mail-Alerts lassen sich fast immer automatisch migrieren.
Process Builder: Setup → Quick Find → "Process Builder". Notieren Sie für jeden aktiven Prozess: Objekt, Trigger-Zeitpunkt (before/after save, scheduled), Anzahl Kriteriengruppen, genutzte Aktionstypen (insbesondere Invocable Actions oder externe Calls).
Salesforce Optimizer Report: Gratis, eingebautes Analyse-Tool. Setup → Quick Find → "Salesforce Optimizer" → Report ausführen. Er zeigt Ihnen Automatisierungen mit Problemen, doppelte Regeln auf demselben Objekt, und Performance-Schwachstellen. Guter erster Überblick.
Erstellen Sie eine Migrationstabelle: Prozessname | Objekt | Aktiv | Aktionstypen | Komplexität (einfach/mittel/komplex) | Priorität. Das gibt Ihnen die Grundlage für eine strukturierte Migration. Und zeigt oft, dass deutlich weniger Aufwand wartet als erwartet.
Schritt 2: Das native "Migrate to Flow"-Tool. Ehrliche Bewertung
Salesforce hat das Migrate-to-Flow-Tool direkt in Setup integriert: Setup → Quick Find → "Migrate to Flow". Es scannt Ihre Workflow Rules und Process Builder-Prozesse und bietet automatische Konvertierung an.
Was es gut kann: Einfache Workflow Rules mit Field Updates, E-Mail-Alerts, und Task-Erstellungen werden oft zuverlässig konvertiert. Ein Klick, Flow ist erstellt, in der Sandbox testen, aktivieren.
Wo es scheitert: Komplexe Process Builder-Prozesse mit mehreren Kriteriengruppen, Invocable Actions, Cross-Object-Updates, oder zeitbasierten Scheduled Actions. Das Tool gibt dann den Status "Partially Migrated" oder "Unable to Migrate" zurück.
Wichtige Regel: Jeden konvertierten Flow vor der Aktivierung manuell reviewen. Das Tool konvertiert mechanisch. Es versteht nicht, ob die Logik sinnvoll ist oder ob es Konsolidierungspotenzial gibt. Konvertierte Flows sind oft ein guter Ausgangspunkt, aber keine fertige Lösung.
AppExchange: Suchen Sie auf dem AppExchange nach "migrate to flow". Es gibt ergänzende Tools von Drittanbietern, die bei der Analyse und Dokumentation Ihrer bestehenden Automatisierungen helfen. Die Auswahl ändert sich, deshalb empfehle ich eine aktuelle Suche statt einer festen Empfehlung. Das native Salesforce-Tool reicht für die meisten Fälle als Startpunkt.
Schritt 3: Die goldene Regel. Migration ist Konsolidierung
Der häufigste Fehler bei der Migration: jede Workflow Rule einzeln als eigenen Flow nachbauen. Das ist das Schlechteste aus zwei Welten. Die Unordnung des alten Systems in neuem Format.
Die goldene Regel lautet: Ein Record-Triggered Flow pro Objekt. Wenn Sie 8 Workflow Rules und 3 Process Builder-Prozesse auf dem Account-Objekt haben, enden Sie mit einem einzigen Record-Triggered Flow, der alle diese Szenarien abdeckt. Über Entry Conditions, Decision-Elemente und Subflows für wiederverwendbare Logik.
Das ist mehr Aufwand als automatische Konvertierung, aber das Ergebnis ist eine wartbare Org. Ich habe Kunden nach der Migration begleitet, die mit einem Bruchteil der Automatisierungskomplexität dasselbe erreichen wie vorher. Und die erstmals seit Jahren verstehen, was ihre Org eigentlich tut.
Zu den Architekturprinzipien für saubere Flows. Von Naming Conventions bis Subflow-Strategie. Finden Sie alles im Flow-Leitfaden.
Schritt 4: Testen ohne Überraschungen
Für jede migrierte Automatisierung gilt dieselbe Teststrategie:
- Sandbox vorbereiten: Produktions-Snapshot in Partial Copy Sandbox (Enterprise) oder Developer Sandbox mit manuell nachgebauten Testdaten.
- Before-State dokumentieren: Test-Record erstellen, den alten Prozess auslösen, exaktes Ergebnis notieren (welche Felder, welche E-Mails, welche Tasks).
- Migration durchführen: Alten Prozess deaktivieren, neuen Flow aktivieren.
- After-State prüfen: Gleichen Test-Record mit denselben Ausgangsdaten erstellen. Ergebnisse vergleichen. Deckungsgleich? Weiter. Abweichung? Flow anpassen.
- Edge Cases testen: Leere Felder, null-Werte, Records die keine Bedingung erfüllen. Der Flow muss in allen Fällen stabil bleiben.
Für zeitgesteuerte Aktionen (Scheduled Paths) Flows im Debug-Modus durchspielen. Salesforce ermöglicht es, den Zeitpunkt im Debug-Modus zu simulieren. Kein Warten auf echte Zeitpunkte nötig.
Die häufigsten Fallstricke
- Parallel laufende alte und neue Automatisierung. Wenn Sie den alten Prozess nicht deaktivieren, bevor der Flow aktiviert ist, feuern beide. Das führt zu doppelten E-Mails, doppelten Tasks, und manchmal widersprüchlichen Field Updates. Immer deaktivieren, dann aktivieren.
- "Evaluate Next Criteria" übersehen. Wenn ein Process Builder-Prozess mehrere Kriteriengruppen hat und das Migrate-to-Flow-Tool nur die erste konvertiert, fehlt nach der Migration die zweite Logik. Jeder konvertierte Flow muss gegen das Original geprüft werden.
- Falsche Flow-Version nach Deployment. Nach einem Sandbox-zu-Produktion-Deployment ist oft die inaktive neue Version in Produktion. Während die alte weiterläuft. Deployment-Checkliste: neue Version aktivieren, alte deaktivieren. Mehr dazu in der Deployment-Nachbereitung.
- Zeitbasierte Workflow-Aktionen nicht migriert. Das Migrate-to-Flow-Tool übernimmt zeitbasierte Aktionen nicht automatisch. Diese müssen manuell als Scheduled Paths im neuen Flow nachgebaut werden.
- Zu viele Flows auf demselben Objekt. Wer jeden alten Prozess als eigenen Flow konvertiert, tauscht eine Unordnung gegen eine andere. Die Migration ist die Chance zur Konsolidierung. Nicht nutzen bedeutet, das Problem in neuem Format weiterzuschleppen.
Häufige Fragen
Bis wann muss ich Process Builder zu Flows migriert haben?
Salesforce hat Process Builder und Workflow Rules als "retired" markiert. Neue Automationen können seit Spring 2023 nicht mehr erstellt werden. Bestehende laufen noch, aber Salesforce kann den Support jederzeit beenden. Migration sollte jetzt Priorität haben.
Wie aufwendig ist die Migration von Process Builder zu Flows?
Einfache Process Builder mit wenigen Aktionen sind in 1-2 Stunden migriert. Komplexe Prozesse mit vielen Verzweigungen und Record-Updates können einen ganzen Tag in Anspruch nehmen. Planen Sie pro Process Builder etwa 2-4 Stunden Migrationsaufwand ein.
Kann Salesforce Process Builder automatisch zu Flows migrieren?
Salesforce bietet ein Migration Tool in Setup, das einfache Process Builder automatisch konvertiert. Komplexere Prozesse müssen manuell überarbeitet werden. Das Tool liefert einen Ausgangspunkt, aber kein produktionsreifes Ergebnis ohne Prüfung.
Was passiert mit meinen bestehenden Process Buildern, wenn ich nichts tue?
Sie laufen aktuell weiter, aber ohne Support und Updates. Bei Salesforce-Releases kann es zu Inkompatibilitäten kommen. Salesforce kann die Funktionalität ohne Ankündigung einschränken. Das Risiko steigt mit jeder weiteren Verzögerung.
Welche Flow-Typen ersetzen Process Builder und Workflow Rules?
Record-Triggered Flows ersetzen Process Builder und Workflow Rules vollständig. Sie triggern bei Record-Erstellung, -Aktualisierung oder -Löschung und können alle Aktionen ausführen, die Process Builder konnte, plus deutlich mehr.
Wenn Sie eine Bestandsaufnahme Ihrer Automatisierungen brauchen oder die Migration strukturiert angehen wollen. Ich helfe Ihnen dabei. Von der Inventarisierung über die Konsolidierungsstrategie bis zum Go-Live in Produktion.
