Process Builder & Workflow Rules: Migration zu Flows

In einem 12 Jahre alten Salesforce-Org habe ich kürzlich 73 Workflow Rules gefunden. Niemand wusste mehr, was sie tun. Manche feuerten doppelt, manche waren tot, eine schickte seit 2017 Outbound Messages an einen Endpoint, der längst offline war. Genau diese Orgs haben jetzt ein Problem.

Wenn Sie 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. Im Spring '26 Release wurden zudem Field Updates auf bestimmten Datums-Feldern als deprecated markiert. Wer das nicht im Release-Note-Audit erwischt hat, schiebt heute Datenfehler durch seine Org, ohne es zu wissen.

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.

SOQL: Vollständige Inventur über die Tooling-API

Setup-Listen reichen für eine erste Sichtung, aber nicht für die Migration. Setup zeigt Ihnen nicht, welche Field Updates oder Outbound Messages eine Rule auslöst, und vor allem nicht, wann sie zuletzt gefeuert hat. Mit Tooling-API und Workbench bekommen Sie die saubere Liste. Beispiel-Query für alle aktiven Workflow Rules:

SELECT Id, Name, TableEnumOrId, NamespacePrefix
FROM WorkflowRule
WHERE Status = 'Active'
ORDER BY TableEnumOrId, Name

Für die zugehörigen Field Updates:

SELECT Id, Name, ObjectType, FieldDefinition.QualifiedApiName
FROM WorkflowFieldUpdate
ORDER BY ObjectType, Name

Ergänzend lohnt der Export aller WorkflowOutboundMessage Records. In meinem 73-Rules-Projekt waren 18 Outbound Messages aktiv, davon 6 mit Endpunkten, die seit Jahren tot waren. Das ist nicht nur Migrations-Backlog. Das sind aktive Sicherheitslücken.

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.

Migrations-Strategie: 1:1, Konsolidierung oder Refactoring

Salesforce bietet das Migrate-to-Flow-Tool als mechanischen Übersetzer an. Das ist ein guter Startpunkt, aber selten die richtige Endlösung. Nach mehreren Migrationsprojekten unterscheide ich drei Strategien:

Strategie 1: 1:1-Migration

Jede Workflow Rule wird zu einem eigenen Record-Triggered Flow. Schnell, niedriges Risiko, aber Sie reproduzieren nur den bestehenden Wildwuchs. Sinnvoll für: kleine Orgs unter 15 Rules, gut dokumentierte Orgs, zeitkritische Projekte. Nicht sinnvoll für gewachsene Enterprise-Orgs mit Performance-Druck.

Strategie 2: Konsolidierung pro Objekt

Pro betroffenem Objekt ein Master-Flow. Dieser Flow wird einmal pro Trigger-Event ausgeführt und bündelt alle Logiken. Das ist die offizielle Salesforce-Empfehlung. Vorteile: ein Eintrittspunkt pro Objekt, weniger Reihenfolge-Probleme, bessere Wartbarkeit. Nachteil: hoher Initialaufwand. Mein Default für Orgs ab 30 Workflow Rules.

Strategie 3: Refactoring mit Funktionsanalyse

Vor der Migration jede Rule auf Existenzberechtigung prüfen. In meinem 73-Rules-Projekt blieben am Ende 41 Flows übrig. 18 Rules waren tot, 14 wurden in andere Logiken integriert. Das ist die Königsdisziplin. Aufwendig, aber Sie kommen mit einer aufgeräumten Automatisierungslandschaft heraus, nicht mit derselben Suppe in neuer Schüssel.

Welche Strategie passt, hängt von zwei Fragen ab: Wie alt ist Ihre Org und wie viel Schmerz haben Sie mit der aktuellen Performance? Junge Orgs profitieren von 1:1, alte Orgs von Refactoring.

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 arbeite ich mit einer dreistufigen Test-Methodik. Sie kostet etwas mehr Zeit als ein direkter Cutover, aber sie verhindert die typischen "Production-Überraschungen", die Migrationen sonst zur Stolperfalle machen.

Phase 1: Parallel-Betrieb in der Sandbox

Neuen Flow aktivieren, alte Workflow Rule weiter laufen lassen. Beide schreiben in unterschiedliche Felder oder triggern unterschiedliche Outbound Messages. Vergleichen Sie die Ergebnisse über mindestens zwei Wochen mit echten Test-Daten. Wenn Diskrepanzen auftauchen, finden Sie sie hier, nicht in Production.

Phase 2: Schatten-Modus in Production

Flow in Production aktivieren, aber mit Logging statt echter Aktion. Logs in ein Custom Object oder Platform Events schreiben, nicht in den eigentlichen Datenpfad. Sie sehen, ob der Flow zur richtigen Zeit feuert, ohne reale Auswirkungen.

Phase 3: Cutover mit Rollback-Plan

Workflow Rule deaktivieren, Flow auf Live-Modus stellen. Rollback-Plan: Bei Problemen Workflow Rule wieder aktivieren, Flow deaktivieren. Genau ein Wochenende Beobachtungszeit, dann Workflow Rule löschen. Keine Halbheiten. Doppelt aktive Automatisierungen sind die Hölle, sobald sie zusammenstoßen.

Für zeitgesteuerte Aktionen (Scheduled Paths) Flows zusätzlich 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.

Workflow-Rules-spezifische Fallen, die ich in Projekten sehe

Outbound Messages verlieren ihre Reihenfolge

Workflow Rules feuern Outbound Messages in einer bestimmten, wenn auch undokumentierten Reihenfolge. Flow Builder garantiert das nicht out-of-the-box. Wenn Sie integrationskritische Reihenfolgen haben (Stripe, ERP, Marketing-Automation), müssen Sie diese explizit im Flow modellieren. Sonst kommen Webhooks in falscher Reihenfolge an, und Ihr ERP verarbeitet ein Update vor der Anlage.

Field Updates auf Datums-Felder

Workflow Rules durften Datums-Felder relativ zu anderen Datums-Feldern setzen, ohne explizite Formel. Das war praktisch, aber undurchsichtig. In Flow müssen Sie diese Logik explizit als Formula Resource modellieren. Wer das übersieht, bekommt nach dem Cutover plötzlich leere oder falsche Datums-Werte. Das fällt oft erst Wochen später auf, wenn Reports merkwürdig aussehen.

Time-Triggers: die größte Falle

Time-Triggered Workflow Actions migrieren NICHT automatisch. Salesforce hat das in der offiziellen Migration-Tool-Doku versteckt: Pending Time-Based Workflow Actions bleiben an die alte Workflow Rule gebunden, auch wenn Sie diese deaktivieren. Sie müssen entweder warten, bis alle Pending Actions abgearbeitet sind, oder Scheduled Paths in Ihrem Flow nachbauen und die Pending Actions manuell migrieren. Planen Sie dafür mindestens vier Wochen Beobachtungszeit ein, wenn Sie Time-Triggers in der Org haben.

Praxistipp: Bauen Sie sich einen Migration-Tracker als Custom Object oder Airtable-Base mit den Spalten Workflow Rule Name, Object, Strategie (1:1 / Konsolidierung / Drop), Owner, Test-Status und Cutover-Datum. Ohne diesen Tracker verlieren Sie nach drei Wochen den Überblick. Mit diesem Tracker sind Sie auch für den nächsten Audit gewappnet.

Häufige Fragen

Schritt-für-Schritt-Anleitung: Process Builder Migration

Alle acht Schritte der Migration von Process Builder zu Flow auf einer Seite. Drucken Sie die Anleitung aus und arbeiten Sie sie für jeden Process Builder in Ihrer Org systematisch ab.

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.