Rodzaje Salesforce Flow: jak wybrać właściwy typ automatyzacji? (kurs Salesforce Flow, lekcja 2)

Otrzymujesz nowe wymaganie biznesowe:

Po utworzeniu zgłoszenia system powinien ustawić priorytet i przypisać właściwy zespół.

Otwierasz Salesforce Flow Builder, wybierasz New Flow i widzisz kilka dostępnych typów automatyzacji: Record-Triggered Flow, Screen Flow, Schedule-Triggered Flow, Autolaunched Flow oraz Platform Event-Triggered Flow.

Który z nich wybrać?

Na początku wszystkie mogą wyglądać jak różne sposoby zbudowania podobnego procesu. W praktyce wybór typu Flow jest jedną z najważniejszych decyzji projektowych.

Dobra wiadomość jest taka, że nie musisz znać wszystkich możliwości platformy, aby podjąć właściwą decyzję. Najczęściej wystarczy odpowiedzieć na jedno pytanie:

Co powinno uruchomić proces?

Wybór rodzaju Flow zaczyna się od punktu uruchomienia procesu.

Zacznij od procesu, a nie od narzędzia

Podczas projektowania automatyzacji łatwo skoncentrować się na tym, co system ma zrobić:

zaktualizować rekord,
utworzyć zadanie,
przypisać właściciela,
wysłać powiadomienie,
przeprowadzić użytkownika przez formularz.

Są to jednak działania wykonywane dopiero po uruchomieniu procesu. Najpierw musimy ustalić, co ten proces rozpoczyna.

Przykład 1: nowe zgłoszenie

Po utworzeniu zgłoszenia system ustawia priorytet i przypisuje zespół. Proces rozpoczyna utworzenie rekordu.

Przykład 2: formularz reklamacji

Pracownik odpowiada na pytania, dodaje dokumenty i zatwierdza dane. Proces rozpoczyna działanie użytkownika.

Przykład 3: wygasające umowy

Każdego dnia system sprawdza umowy, których termin zakończenia się zbliża. Proces rozpoczyna harmonogram.

Przykład 4: wspólne obliczanie priorytetu

Kilka automatyzacji korzysta z tych samych reguł klasyfikacji. Proces rozpoczyna wywołanie przez inną automatyzację.

Przykład 5: awaria z systemu zewnętrznego

System monitoringu publikuje informację o wykryciu awarii. Proces rozpoczyna zdarzenie.

W każdym przypadku Salesforce może pracować na podobnych danych. Różni się jednak sposób rozpoczęcia procesu. To właśnie ten sposób najczęściej prowadzi nas do właściwego typu Flow.

Pięć podstawowych rodzajów Salesforce Flow

Skupimy się na pięciu typach. Nie musisz od razu zapamiętywać wszystkich szczegółów. Najważniejsze jest zrozumienie, na jaki rodzaj zdarzenia reaguje każdy z nich.

Record-Triggered Flow
Screen Flow
Schedule-Triggered Flow
Autolaunched Flow
Platform Event-Triggered Flow

1. Record-Triggered Flow

Record-Triggered Flow uruchamia się w reakcji na operację dotyczącą rekordu. Może reagować na jego utworzenie, aktualizację albo usunięcie.

Jeżeli wymaganie zaczyna się od słów „po utworzeniu rekordu” albo „gdy zmieni się wartość pola”, Record-Triggered Flow powinien być jednym z pierwszych rozważanych rozwiązań.

Record-Triggered Flow reaguje na istotną zmianę rekordu.

Przykład: obsługa zgłoszeń

Po utworzeniu zgłoszenia Flow sprawdza kategorię problemu i typ klienta, ustawia priorytet, przypisuje odpowiedni zespół oraz tworzy zadanie dla właściciela.

Przykład: wygrana sprzedaż

Gdy Opportunity przechodzi do etapu Closed Won, Flow może utworzyć projekt wdrożeniowy, przygotować zadania onboardingowe i powiadomić dział realizacji.

Na co uważać?

Najczęstszym błędem jest uruchamianie automatyzacji przy każdej aktualizacji rekordu. Jeżeli proces dotyczy wyłącznie zmiany statusu, nie powinien wykonywać się po zmianie opisu lub innego niezwiązanego pola.

Jaka dokładnie zmiana powinna rozpocząć ten proces?

2. Screen Flow

Screen Flow wykorzystujemy, gdy użytkownik musi uczestniczyć w procesie. Może wyświetlać informacje, zadawać pytania, zbierać dane, reagować na odpowiedzi i pokazywać podsumowanie.

Screen Flow nie powinien być traktowany wyłącznie jako kolejny formularz. Jego zadaniem jest pomóc użytkownikowi poprawnie przejść przez proces.

Screen Flow prowadzi użytkownika przez kolejne etapy.

Przykład: rejestracja reklamacji

wyszukanie klienta,
wybór rodzaju reklamacji,
odpowiedzi na pytania zależne od kategorii,
dodanie opisu i załączników,
sprawdzenie podsumowania,
utworzenie zgłoszenia.

Przykład: kwalifikacja potencjalnego klienta

Handlowiec odpowiada na pytania dotyczące firmy, potrzeb, budżetu i terminu zakupu. Na podstawie odpowiedzi Flow może obliczyć wynik kwalifikacji i zasugerować następny krok.

Na co uważać?

Jeżeli użytkownik widzi kilkadziesiąt pól, długie instrukcje i wiele opcji, proces nie został uproszczony. Jego złożoność została jedynie przeniesiona na użytkownika.

Na danym ekranie pokazuj tylko informacje potrzebne do wykonania aktualnego kroku.

3. Schedule-Triggered Flow

Schedule-Triggered Flow działa zgodnie z ustalonym harmonogramem. Nie czeka na zmianę pojedynczego rekordu ani na działanie użytkownika. W określonym czasie wyszukuje rekordy spełniające zdefiniowane warunki.

Schedule-Triggered Flow wykonuje proces według harmonogramu.

Przykład: zgłoszenia bez odpowiedzi

Codziennie rano system sprawdza otwarte zgłoszenia. Jeżeli sprawa pozostaje bez odpowiedzi zbyt długo, Flow tworzy zadanie, wysyła przypomnienie i może oznaczyć zgłoszenie do eskalacji.

Przykład: odnowienia umów

System codziennie wyszukuje umowy kończące się w ciągu najbliższych 30 dni. Następnie może utworzyć zadanie dla opiekuna, wysłać przypomnienie lub przygotować Opportunity dotyczącą przedłużenia.

Na co uważać?

Harmonogram nie powinien być rozwiązaniem zastępczym dla niejasnego punktu uruchomienia. „Po zmianie statusu” sugeruje Record-Triggered Flow. „Każdego dnia sprawdzaj rekordy” sugeruje Schedule-Triggered Flow.

4. Autolaunched Flow

Autolaunched Flow działa bez ekranów i jest uruchamiany przez inny proces. Najłatwiej myśleć o nim jak o wspólnym module, który otrzymuje dane, wykonuje określoną logikę i zwraca rezultat lub wykonuje działania.

Autolaunched Flow jako wspólny moduł logiki.

Przykład: obliczanie priorytetu

Te same reguły klasyfikacji są wykorzystywane w portalu klienta, procesie telefonicznym i integracji. Zamiast kopiować logikę trzy razy, można wykorzystać jeden wspólny Autolaunched Flow.

Przykład: wspólne logowanie błędów

Kilka automatyzacji może przekazywać do wspólnego Flow nazwę procesu, identyfikator rekordu, komunikat błędu oraz kontekst. Moduł tworzy rekord logu i powiadamia właściwą osobę.

Na co uważać?

Nie każda grupa elementów powinna zostać osobnym Flow. Zbyt duża liczba małych modułów może utrudnić zrozumienie procesu. Moduł warto wydzielić, gdy ma konkretną odpowiedzialność i rzeczywiście ogranicza duplikację.

5. Platform Event-Triggered Flow

Platform Event-Triggered Flow reaguje na opublikowane zdarzenie.

Rekord opisuje aktualny stan danych. Zdarzenie informuje, że coś się wydarzyło.

Platform Event-Triggered Flow reaguje na komunikat o zdarzeniu.

Przykład: awaria urządzenia

System monitorujący publikuje zdarzenie zawierające identyfikator urządzenia, typ problemu i poziom ważności. Flow odbiera zdarzenie, odnajduje klienta, tworzy zgłoszenie i przypisuje odpowiedni zespół.

Przykład: zaksięgowanie płatności

Zewnętrzny system finansowy publikuje informację o płatności. Flow może zaktualizować status rozliczenia, odblokować kolejny etap usługi i powiadomić opiekuna klienta.

Na co uważać?

Platform Events nie należy stosować tylko dlatego, że architektura zdarzeniowa brzmi nowocześnie. Takie rozwiązanie trzeba monitorować, dokumentować i utrzymywać. Najpierw warto sprawdzić, czy problemu nie rozwiąże prostsza reakcja na zmianę danych.

Jeden proces, kilka rodzajów Flow

Ten sam obszar biznesowy może wykorzystywać różne typy Flow. Weźmy obsługę zgłoszeń:

Screen Flow prowadzi konsultanta przez rejestrację zgłoszenia.
Record-Triggered Flow ustala priorytet po utworzeniu rekordu.
Schedule-Triggered Flow sprawdza zgłoszenia pozostające bez odpowiedzi.
Autolaunched Flow przechowuje wspólne reguły klasyfikacji.
Platform Event-Triggered Flow reaguje na awarię zgłoszoną przez system monitoringu.

Jeden proces biznesowy może wykorzystywać kilka typów Flow.

Typ Flow nie zależy więc wyłącznie od obiektu, na którym pracujemy. Zależy od odpowiedzialności danego fragmentu procesu.

Jak szybko wybrać typ Flow?

Co rozpoczyna proces?	Najbardziej naturalny kandydat
Utworzenie, aktualizacja lub usunięcie rekordu	Record-Triggered Flow
Działanie i decyzje użytkownika	Screen Flow
Określony termin lub harmonogram	Schedule-Triggered Flow
Wywołanie przez inny proces	Autolaunched Flow
Opublikowane zdarzenie	Platform Event-Triggered Flow

To punkt wyjścia, a nie ostateczna decyzja. Nadal trzeba uwzględnić skalę, dostępne dane, błędy i inne automatyzacje działające w organizacji.

Checklista przed utworzeniem Flow

Przed otwarciem Flow Buildera odpowiedz na pięć pytań:

Co rozpoczyna proces?
Czy użytkownik musi w nim uczestniczyć?
Kiedy proces powinien zostać wykonany?
Jakie dane są potrzebne?
Czy część logiki będzie wykorzystywana ponownie?

Jeżeli odpowiedzi nie są jednoznaczne, warto wrócić do analizy procesu. Niejasność na tym etapie zwykle prowadzi do problemów podczas implementacji.

Podsumowanie

Nie istnieje jeden rodzaj Salesforce Flow odpowiedni dla każdego procesu.

Record-Triggered Flow reaguje na operacje dotyczące rekordów.
Screen Flow prowadzi użytkownika przez kolejne kroki.
Schedule-Triggered Flow wykonuje działania według harmonogramu.
Autolaunched Flow udostępnia wspólną logikę.
Platform Event-Triggered Flow reaguje na opublikowane zdarzenia.

Wybieraj rodzaj Flow na podstawie początku procesu.

Najważniejsze pytanie pozostaje zawsze takie samo:

Co rozpoczyna proces?

Przed rozpoczęciem budowy spróbuj uzupełnić zdanie:

Kiedy wydarzy się __________, proces powinien zostać uruchomiony jako __________, ponieważ __________.

Jeżeli potrafisz precyzyjnie uzupełnić wszystkie części, masz solidną podstawę do wyboru właściwego rodzaju Flow. Jeżeli nie, problemem prawdopodobnie nie jest brak znajomości narzędzia. Sam proces wymaga dalszej analizy.

Sprawdź się

1. Wymaganie brzmi: „Każdego dnia o 7:00 sprawdź zgłoszenia bez odpowiedzi”. Który typ Flow wybierzesz?

Pokaż odpowiedź

Schedule-Triggered Flow. Proces rozpoczyna harmonogram, a nie zmiana pojedynczego rekordu ani działanie użytkownika.

2. Te same reguły wyznaczania priorytetu są potrzebne w trzech różnych procesach. Jak uniknąć kopiowania logiki?

Pokaż odpowiedź

Wydzielić ją do Autolaunched Flow, który działa jak wspólny moduł i jest wywoływany przez pozostałe procesy.

3. Czym różni się rekord od zdarzenia platformowego (Platform Event)?

Pokaż odpowiedź

Rekord opisuje aktualny stan danych. Zdarzenie informuje, że coś się wydarzyło, np. system monitoringu wykrył awarię. Platform Event-Triggered Flow reaguje właśnie na takie komunikaty.

Następny krok: w kolejnej lekcji zajmiemy się jedną z najważniejszych decyzji przy projektowaniu Record-Triggered Flow: kiedy zastosować Before-Save, a kiedy After-Save.