Automatyzacja procesów biznesowych z Salesforce Flow

31 grudnia 2025 roku Salesforce zakończył wsparcie dla Workflow Rules i Process Buildera. Istniejące automatyzacje nadal działają, ale bez poprawek błędów i bez supportu — a nowych nie można tworzyć już od 2023 roku. Flow jest dziś jedynym rozwijanym narzędziem automatyzacji deklaratywnej na platformie i jednocześnie warstwą akcji dla agentów AI z Agentforce. Jeśli w Twoim orgu wciąż działają stare reguły, migracja przestała być kwestią „czy”, a stała się kwestią „jak szybko”.

Dlaczego Flow?

Poza oczywistym argumentem (koniec wsparcia starych narzędzi) Flow po prostu potrafi więcej: logika warunkowa, pętle, transakcje na wielu obiektach, ekrany dla użytkownika i wywołania zewnętrznych systemów — wszystko bez linijki kodu. Do przeniesienia prostych reguł służy wbudowane narzędzie Migrate to Flow, które klasyfikuje automatyzacje jako w pełni, częściowo lub niemożliwe do automatycznej migracji. Z doświadczenia: proste reguły warto migrować narzędziem, a złożone procesy przeprojektować od zera — mechaniczne przenoszenie bałaganu tylko go utrwala.

Typy Flow i kiedy którego używać

• Record-Triggered — uruchamiany przy tworzeniu, edycji lub usunięciu rekordu. Wariant before-save do szybkich aktualizacji pól (najwydajniejszy, bez dodatkowego DML), after-save gdy potrzebujesz Id rekordu, rekordów powiązanych lub integracji.
• Screen Flow — interakcja z użytkownikiem: guided selling, wizardy, formularze wieloetapowe.
• Schedule-Triggered — cykliczne zadania wsadowe, np. czyszczenie danych.
• Autolaunched — logika wielokrotnego użytku wywoływana z Apex, API lub jako subflow.
• Platform Event-Triggered — architektura event-driven i asynchroniczne integracje.

Przykładowa konfiguracja

Klasyczna automatyzacja sprzedażowa — po wygranej szansie tworzymy zadania onboardingowe:

Record-Triggered Flow (after-save)
  → Object: Opportunity
  → Trigger: A record is created or updated
  → Entry condition: Stage = "Closed Won" (Is Changed)
  → Action: Create Records — zadania onboardingowe
  → Action: Update Records — status konta na "Customer"
  → Fault path: log błędu + powiadomienie admina

Inne sprawdzone scenariusze: przydział leadów round-robin lub po terytorium, eskalacja case’ów przekraczających SLA z alertem na Slacku, follow-upy przy stagnacji opportunity.

Najlepsze praktyki

Zasada „one flow per object” to dziedzictwo ery triggerów Apex. Obecnie rekomendowany wzorzec to osobne flow before-save i after-save na obiekt plus precyzyjne entry conditions — zamiast jednego gigantycznego flow z drzewem decyzyjnym na pół ekranu.

• Bulkifikacja: nigdy Get/Create/Update/Delete wewnątrz pętli. Rekordy zbieramy do kolekcji i wykonujemy DML raz, poza pętlą.
• Fault paths na każdym elemencie DML plus centralny subflow do logowania błędów — cichy błąd automatyzacji to najgorszy rodzaj błędu.
• Subflows dla logiki wielokrotnego użytku; pamiętaj, że działają synchronicznie w tej samej transakcji, więc też muszą być bulk-safe.
• Limity governor na transakcję: 100 zapytań SOQL, 150 operacji DML, 50 000 pobranych rekordów, 10 s czasu CPU. Flow, który działa na jednym rekordzie w sandboxie, potrafi wywrócić się na imporcie 5 000 rekordów na produkcji.

Automatyzacja, której nikt nie dokumentuje i nie testuje na wolumenie, to nie oszczędność czasu — to odroczony incydent.

Co nowego we Flow (2026)

Spring ‘26 przyniósł budowanie i modyfikowanie Flow w języku naturalnym przez panel Agentforce, edytowalne tabele danych w Screen Flows, natywny komponent Kanban i Flow Logging z obserwowalnością na produkcji. Kierunek jest czytelny: Flow staje się warstwą wykonawczą dla agentów AI — im czystsze automatyzacje dziś, tym łatwiejsze wdrożenie Agentforce jutro.

Źródła: Salesforce Help — Workflow Rules & Process Builder End of Support, Salesforce Ben — Types of Flow, Salesforce Ben — Flow Features in Spring ‘26, Salesforce Ben — Flow Limits, Beyond the Cloud — Bulkification in Flows