Salesforce Flow: typy automatyzacji i kiedy co stosować

Record-triggered flow aktualizuje rekord Salesforce dziesięć razy szybciej niż ten sam proces zbudowany w Process Builder (Trailhead, oficjalna dokumentacja Salesforce). To zdanie pojawiło się w materiałach szkoleniowych Salesforce nie bez powodu: Flow Builder nie jest prostszą alternatywą dla Apex ani estetycznym ulepszeniem Workflow Rules – to fundamentalna zmiana podejścia do automatyzacji na platformie. Process Builder i Workflow Rules mają oficjalnie zakończone wsparcie na koniec 2025 roku. Jeśli Twój org nadal na nich stoi, ten artykuł jest dla Ciebie.

Flow Builder jako pojedynczy dom automatyzacji

Flow Builder to interfejs wizualny dostępny przez Setup → Flows. Zastępuje trzy starsze narzędzia: Workflow Rules (reguły workflow dla prostych automatyzacji), Process Builder (bardziej rozbudowana logika warunkowa) i Salesforce Flow pierwszej generacji. Każde z nich rozwiązywało inny podzbiór problemów – Flow Builder łączy ich możliwości z istotnie większą elastycznością i wydajnością.

Kluczowe pojęcie: Flow to przepływ sterowania przez elementy logiczne. Każdy flow definiujesz przez wybór triggera (co go uruchamia), warunki wejściowe (kiedy ma działać) i akcje (co ma robić). Flow może tworzyć i aktualizować rekordy, wysyłać emaile, wywoływać Apex, inicjować integracje przez Externe Services, uruchamiać inne Flow jako subflow lub wyświetlać interfejs użytkownikowi. Ten ostatni wariant – Screen Flow – sprawia, że Flow wychodzi poza „automatyzację w tle” i staje się narzędziem do budowania interfejsów użytkownika bez Visualforce i LWC.

Ważna informacja operacyjna: Flow dzieli governor limits z Apex. Jeśli Record-Triggered Flow i Apex trigger działają na tym samym zdarzeniu, ich zapytania SOQL i operacje DML sumują się w ramach jednej transakcji. Przy projektowaniu automatyzacji w orgu z istniejącym kodem Apex warto sprawdzić Flow Trigger Explorer, żeby zobaczyć wszystkie automatyzacje na danym obiekcie i zdarzeniu.

Pięć typów Flow i kiedy po który sięgnąć

Record-Triggered Flow to najczęściej używany typ – odpowiednik Workflow Rules i Process Builder, ale znacznie potężniejszy. Uruchamia się automatycznie gdy rekord jest tworzony, aktualizowany lub usuwany. Masz dwa podtypy wykonania:

Before Save (Fast Field Updates): wykonuje się przed zapisem rekordu do bazy danych. Możesz modyfikować pola triggering record bez osobnego DML – rekord i tak jest w drodze do bazy. Szybsze i tańsze obliczeniowo. Ograniczenie: nie możesz w nim tworzyć rekordów powiązanych ani wykonywać calloutów. Używaj do prostych kalkulacji i aktualizacji pól na tym samym obiekcie.

After Save: wykonuje się po zapisie. Rekord ma już ID, możesz tworzyć rekordy powiązane, wysyłać emaile, wołać Apex. Potrzebuje osobnego DML dla ewentualnych zmian na triggering record. Używaj gdy logika wymaga dostępu do ID rekordu lub pracy z rekordami powiązanymi.

Screen Flow to jedyny typ z interfejsem użytkownika. Wyświetla ekrany z formularzami, tekstem, obrazami lub wyborem opcji. Uruchamiany ręcznie przez użytkownika – z przycisku na stronie rekordu, Quick Action, Utility Bar lub osadzony na Lightning Page. Zastępuje wiele starszych Visualforce pages dla scenariuszy wieloetapowych formularzy, wizardów konfiguracyjnych i interaktywnych procesów zatwierdzania.

Schedule-Triggered Flow uruchamia się o określonej godzinie: jednorazowo, codziennie lub co tydzień. Przetwarza rekordy spełniające zdefiniowane kryteria w trybie batchowym. Limity: do 50 000 rekordów per uruchomienie, porcje po 200 rekordów. Dla większych wolumenów – Batch Apex. Używaj do cyklicznych zadań utrzymaniowych: eskalowania starych przypadków, aktualizacji statusów wygasłych rekordów, wysyłania przypomnień.

Autolaunched Flow (bez triggera) nie startuje sam – jest wywoływany przez inny Flow (jako subflow), przez Apex, przez REST API lub przez przycisk. Jego siła to reużywalność: logika zdefiniowana raz, wywoływana z wielu miejsc. Jeśli ta sama sekwencja operacji pojawia się w kilku flowach, wydziel ją do Autolaunched Flow i wołaj jako subflow.

Platform Event-Triggered Flow subskrybuje zdarzenia platformy (Platform Events) – zarówno wewnętrzne jak i zewnętrzne. Idealne do architektur eventowych, gdzie zewnętrzny system publikuje event, a Salesforce reaguje w tle.

Scheduled Path: kiedy chcesz opóźnione działanie w Record-Triggered Flow

Record-Triggered Flow ma dodatkową możliwość: Scheduled Path. To ścieżka wykonania, która uruchamia się nie natychmiast po triggering event, ale po określonym czasie – minutach, godzinach, dniach lub miesiącach od zdarzenia lub od wartości pola na rekordzie.

Przykład: Flow na Opportunity uruchamiany przy zamknięciu (Closed Won) ma Immediate Path (tworzy kontrakt natychmiast) i Scheduled Path „5 dni po Close Date” (tworzy zadanie dla opiekuna klienta do follow-up). Jedna definicja Flow obsługuje oba scenariusze. Scheduled Path jest dostępny tylko gdy Flow jest ustawiony na tryb „Actions and Related Records” (after save).

Różnica między Scheduled Path a Schedule-Triggered Flow: Scheduled Path jest powiązany z konkretnym zdarzeniem na rekordzie i uruchamia się raz na rekord. Schedule-Triggered Flow uruchamia się niezależnie od zdarzeń, przetwarza wszystkie rekordy spełniające kryteria w danym momencie. Jeśli chcesz emaila 5 dni po zamknięciu szansy – Scheduled Path. Jeśli chcesz cotygodniowego raportu o wszystkich szansach zamkniętych przez ostatnie 7 dni – Schedule-Triggered Flow.

Migracja z Process Builder i Workflow Rules: co zrobić teraz

Process Builder i Workflow Rules mają zakończone wsparcie z końcem 2025 roku (Salesforce Ben). Zakończenie wsparcia nie oznacza automatycznego wyłączenia – istniejące automatyzacje nadal działają – ale oznacza brak poprawek błędów i aktualizacji. Jeśli któraś z automatyzacji przestanie działać po release Salesforce, support nie pomoże.

Priorytetyzacja migracji: zacznij od automatyzacji najważniejszych procesów biznesowych i tych, które łączą wiele warunków lub akcji (te są bardziej narażone na problemy przy przyszłych zmianach platformy). Proste Workflow Rules z jedną akcją emailową to niskie ryzyko, można migrować stopniowo. Złożone Process Builderów – im szybciej, tym lepiej.

Flow Trigger Explorer (Setup → Flow) pokazuje wszystkie aktywne automatyzacje per obiekt i zdarzenie. To punkt startowy audytu. Salesforce udostępnia też oficjalne narzędzie do migracji Process Builder do Flow, choć wymaga ono weryfikacji po migracji – mechaniczne przetłumaczenie nie zawsze daje najlepszą architekturę. Jak rola Admina zmienia się w kontekście automatyzacji i AI, opisujemy w artykule o Admin w erze agentów po TDX 2026. Przegląd zakresu egzaminu dla Admina, gdzie Flow zajmuje 15% punktacji, znajdziesz w artykule o certyfikacie Salesforce Administrator.

Flow Builder jest dziś jedynym właściwym miejscem dla deklaratywnej automatyzacji w Salesforce. Pytanie nie brzmi już „czy migrować”, ale „od czego zacząć”. Jakie automatyzacje w Twoim orgu nadal działają na Process Builder lub Workflow Rules?