Czym jest Salesforce Flow i kiedy warto go używać?
Czym jest Salesforce Flow, jakie problemy rozwiązuje, z jakich części składa się automatyzacja i kiedy Flow jest dobrym wyborem, a kiedy trzeba się zatrzymać.
Wyobraź sobie, że po utworzeniu zgłoszenia pracownik musi sprawdzić dane klienta, ustawić priorytet, wybrać odpowiedni zespół i utworzyć zadanie dla osoby odpowiedzialnej.
Każda z tych czynności jest prosta. Problem pojawia się wtedy, gdy trzeba je wykonywać wielokrotnie, według tych samych zasad i bez pomyłek.
Czy użytkownik powinien za każdym razem pamiętać o wszystkich krokach? A może część tej pracy powinien wykonać system?
Właśnie do takich zadań służy Salesforce Flow.
Flow pozwala automatyzować procesy biznesowe działające w Salesforce. Może reagować na zmiany danych, podejmować decyzje, wykonywać działania oraz prowadzić użytkownika przez kolejne etapy procesu.
Samo poznanie Flow Buildera nie wystarczy jednak do tworzenia dobrych automatyzacji. Zanim rozpoczniemy budowę, powinniśmy najpierw zrozumieć problem, dane i oczekiwany rezultat.
W tej lekcji dowiesz się:
- czym jest Salesforce Flow,
- jakie problemy można rozwiązać za jego pomocą,
- z jakich części składa się automatyzacja,
- kiedy Flow jest dobrym wyborem,
- kiedy należy zatrzymać się przed rozpoczęciem implementacji.
Automatyzacja zaczyna się przed otwarciem Flow Buildera
Jednym z najczęstszych błędów jest rozpoczynanie pracy od narzędzia.
Otwieramy Flow Builder, dodajemy pierwszy element i dopiero wtedy próbujemy ustalić, jak powinien działać cały proces.
Taka metoda może sprawdzić się w bardzo prostych automatyzacjach. Przy większych rozwiązaniach szybko prowadzi jednak do rozbudowanych diagramów, powielonej logiki i trudnych do przewidzenia wyjątków.
Projektowanie Flow powinno zaczynać się od pytań:
- Co rozpoczyna proces?
- Jakie dane są potrzebne?
- Jakie warunki wpływają na jego przebieg?
- Jakie działania powinien wykonać system?
- Jaki rezultat chcemy osiągnąć?
- Co powinno wydarzyć się w przypadku błędu?
Odpowiedzi tworzą podstawowy model procesu. Dopiero na jego podstawie możemy zdecydować, w jaki sposób zbudować automatyzację.
Rysunek 1. Proces ręczny i automatyzacja z Salesforce Flow.
Czym jest Salesforce Flow?
Salesforce Flow to narzędzie służące do automatyzowania procesów w Salesforce.
Za jego pomocą możemy zbudować proces, który:
- reaguje na utworzenie lub zmianę rekordu,
- pobiera dane z Salesforce,
- sprawdza warunki biznesowe,
- wybiera odpowiednią ścieżkę,
- tworzy lub aktualizuje rekordy,
- wykonuje dodatkowe działania,
- prowadzi użytkownika przez interaktywny formularz,
- przekazuje dane do innych elementów rozwiązania.
Flow nie jest więc wyłącznie narzędziem do automatycznej zmiany wartości pól. Może obsługiwać prostą operację wykonywaną w tle, ale także bardziej rozbudowany proces biznesowy.
Najprościej można opisać go za pomocą czterech elementów:
Zdarzenie uruchamia proces. Proces korzysta z danych, podejmuje decyzje i wykonuje działania.
To właśnie połączenie tych elementów tworzy automatyzację.
Cztery podstawowe możliwości Flow
1. Reagowanie na zdarzenia
Każdy proces musi mieć swój początek.
Automatyzacja może zostać uruchomiona między innymi przez:
- utworzenie rekordu,
- zmianę określonego pola,
- działanie użytkownika,
- nadejście ustalonego terminu,
- zdarzenie pochodzące z innego procesu.
Punkt uruchomienia ma duży wpływ na dalszy projekt rozwiązania. Inaczej zaprojektujemy proces działający automatycznie po zmianie danych, a inaczej formularz uruchamiany świadomie przez użytkownika.
Dlatego jednym z pierwszych pytań powinno być:
Co dokładnie powoduje rozpoczęcie procesu?
Jeżeli nie potrafimy odpowiedzieć na to pytanie, prawdopodobnie nie jesteśmy jeszcze gotowi do rozpoczęcia implementacji.
2. Praca z danymi
Flow może korzystać z danych przechowywanych w Salesforce.
Mogą to być na przykład:
- informacje o kliencie,
- status zgłoszenia,
- właściciel rekordu,
- wartość zamówienia,
- typ produktu,
- data ostatniego kontaktu,
- dane znajdujące się na rekordach powiązanych.
Proces może odczytać te informacje, wykorzystać je do podjęcia decyzji, a następnie utworzyć lub zmodyfikować odpowiednie rekordy.
Nie oznacza to jednak, że Flow powinien pobierać wszystkie dostępne dane. Każda informacja używana w procesie powinna mieć jasno określone zastosowanie.
Przed pobraniem danych warto zapytać:
- Czy ta informacja wpływa na decyzję?
- Czy jest potrzebna do wykonania działania?
- Czy znajduje się już w kontekście uruchomionego procesu?
- Co stanie się, jeśli nie będzie dostępna?
Takie podejście pomaga ograniczyć niepotrzebne operacje i upraszcza rozwiązanie.
3. Podejmowanie decyzji
Proces biznesowy nie zawsze przebiega w identyczny sposób. Jego dalszy kierunek często zależy od danych.
Przykładowo:
- jeśli zgłoszenie ma wysoki priorytet, powinno trafić do zespołu szybkiego reagowania,
- jeśli klient jest klientem strategicznym, może obowiązywać krótszy czas obsługi,
- jeśli wartość zamówienia przekracza określony poziom, może być wymagana dodatkowa akceptacja,
- jeśli brakuje wymaganych danych, proces nie powinien być kontynuowany.
Flow pozwala odwzorować takie reguły i skierować proces na właściwą ścieżkę.
Warunki powinny być jednak jednoznaczne. Dobrze zaprojektowana decyzja odpowiada na konkretne pytanie.
- Czy priorytet zgłoszenia jest wysoki?
- Czy status rekordu rzeczywiście się zmienił?
- Czy wszystkie wymagane dane zostały uzupełnione?
- Czy klient spełnia warunki specjalnej obsługi?
Im bardziej precyzyjne pytanie, tym łatwiej zrozumieć i przetestować logikę procesu.
4. Wykonywanie działań
Po przeanalizowaniu danych i podjęciu decyzji Flow może wykonać odpowiednie działania.
W zależności od rodzaju procesu mogą one obejmować:
- zmianę wartości pola,
- utworzenie nowego rekordu,
- aktualizację rekordów powiązanych,
- przypisanie właściciela,
- utworzenie zadania,
- wysłanie powiadomienia,
- uruchomienie dodatkowej automatyzacji,
- przekazanie danych do dalszego przetwarzania.
Każde działanie powinno wynikać z konkretnego wymagania biznesowego.
Jeżeli nie potrafimy wyjaśnić, dlaczego dana operacja jest potrzebna, powinniśmy zastanowić się, czy rzeczywiście należy umieszczać ją w procesie.
Flow jako interfejs dla użytkownika
Nie każdy Flow musi działać całkowicie w tle.
Salesforce Flow może również prowadzić użytkownika przez kolejne etapy procesu. Na ekranach można wyświetlać informacje, zadawać pytania, zbierać dane oraz dostosowywać następne kroki do wcześniejszych odpowiedzi.
Takie rozwiązanie może wspierać między innymi:
- rejestrowanie zgłoszenia,
- przygotowanie oferty,
- kwalifikację klienta,
- zbieranie danych potrzebnych do realizacji procesu,
- przeprowadzenie konsultanta przez rozmowę,
- tworzenie kilku powiązanych rekordów w ramach jednego formularza.
W takim przypadku Flow nie tylko automatyzuje operacje, ale staje się także interfejsem prowadzącym użytkownika przez proces.
Dobrze zaprojektowany formularz nie powinien jednak przenosić całej złożoności systemu na użytkownika. Powinien pokazywać tylko te informacje i pytania, które są potrzebne na danym etapie.
Z jakich części składa się automatyzacja?
Większość procesów Flow można opisać za pomocą sześciu podstawowych elementów.
Rysunek 2. Anatomia automatyzacji w Salesforce Flow.
1. Zdarzenie
Określa, co rozpoczyna proces. Może to być zmiana danych, działanie użytkownika, określony termin lub inne zdarzenie dostępne w systemie.
2. Dane
Określają informacje potrzebne do wykonania procesu. Część danych może być dostępna od momentu uruchomienia Flow. Pozostałe informacje mogą wymagać pobrania z innych rekordów.
3. Warunki
Określają, czy proces powinien być kontynuowany i która ścieżka powinna zostać wybrana. Warunki powinny być czytelne, jednoznaczne oraz możliwe do przetestowania.
4. Działania
Opisują operacje, które zostaną wykonane przez system. Każde działanie powinno mieć jasno określony cel.
5. Rezultat
Określa oczekiwany efekt automatyzacji. Może nim być zaktualizowany rekord, utworzone zadanie, przypisany właściciel albo zakończony proces prowadzony przez użytkownika.
6. Obsługa błędu
Określa zachowanie procesu, gdy operacja nie może zostać wykonana.
Flow może nie zakończyć się poprawnie między innymi z powodu:
- braku wymaganych danych,
- niewystarczających uprawnień,
- błędu podczas aktualizacji rekordu,
- reguły walidacji,
- konfliktu z inną automatyzacją,
- niedostępności zewnętrznego systemu.
Dlatego projekt nie powinien ograniczać się wyłącznie do poprawnej ścieżki.
Przykład: klasyfikacja zgłoszenia klienta
Firma przyjmuje zgłoszenia od różnych rodzajów klientów. Jeżeli klient strategiczny zgłosi awarię, sprawa powinna otrzymać wysoki priorytet i trafić do odpowiedniego zespołu.
Rysunek 3. Klasyfikacja zgłoszenia klienta.
Proces ręczny
Po utworzeniu zgłoszenia pracownik musi:
- sprawdzić typ klienta,
- sprawdzić kategorię zgłoszenia,
- określić priorytet,
- wybrać odpowiedni zespół,
- przypisać właściciela,
- zapisać zmiany.
Każdy krok zależy od wiedzy i uwagi użytkownika. Jeżeli pracownik pominie jeden z nich albo niewłaściwie zinterpretuje reguły, zgłoszenie może trafić do niewłaściwego zespołu lub zostać obsłużone z opóźnieniem.
Proces zautomatyzowany
Po zastosowaniu Flow proces może wyglądać następująco:
- Utworzenie zgłoszenia uruchamia automatyzację.
- Flow sprawdza kategorię zgłoszenia.
- Proces odczytuje typ klienta.
- Flow porównuje dane z regułami biznesowymi.
- System ustala priorytet.
- Zgłoszenie zostaje przypisane do odpowiedniego zespołu.
- Wynik procesu zostaje zapisany.
Jeżeli zgłoszenie dotyczy awarii, a klient należy do grupy klientów strategicznych, Flow może automatycznie ustawić wysoki priorytet i skierować sprawę do zespołu odpowiedzialnego za pilne przypadki.
Co naprawdę daje taka automatyzacja?
Technicznie Flow zmienia kilka wartości na rekordzie. To jednak nie sama aktualizacja pól jest najważniejsza.
Wartością biznesową jest:
- spójne stosowanie reguł,
- ograniczenie liczby ręcznych czynności,
- zmniejszenie ryzyka błędnej klasyfikacji,
- szybsze przekazanie sprawy do właściwego zespołu,
- możliwość łatwiejszego analizowania i rozwijania procesu.
Dobrą automatyzację należy więc oceniać nie tylko na podstawie wykonywanych operacji, ale również jej wpływu na cały proces biznesowy.
Kiedy Flow jest dobrym wyborem?
Flow warto rozważyć, gdy:
- proces ma jednoznaczny punkt rozpoczęcia,
- potrzebne dane są dostępne dla automatyzacji,
- reguły biznesowe można opisać za pomocą konkretnych warunków,
- wiemy, jakie działania powinien wykonać system,
- potrafimy wskazać oczekiwany rezultat,
- znamy podstawowe wyjątki i możliwe błędy,
- automatyzacja ograniczy pracę ręczną lub zwiększy spójność procesu,
- rozwiązanie mieści się w możliwościach Flow.
Jeżeli większość tych warunków jest spełniona, Flow może być właściwym narzędziem. Nadal potrzebna jest jednak ocena złożoności, skali oraz wpływu rozwiązania na pozostałe automatyzacje.
Rysunek 4. Kiedy Flow jest dobrym wyborem?
To, że rozwiązanie można zbudować za pomocą Flow, nie oznacza jeszcze, że Flow jest najlepszym wyborem.
Kiedy należy zatrzymać się przed rozpoczęciem budowy?
Projektant Flow powinien wiedzieć nie tylko, jak zbudować automatyzację, ale również kiedy nie należy jeszcze rozpoczynać implementacji.
Dodatkowa analiza jest potrzebna, gdy:
- reguły procesu nie są jednoznaczne,
- osoby zaangażowane w projekt różnie opisują oczekiwany rezultat,
- nie wiadomo, co powinno uruchamiać proces,
- kilka automatyzacji modyfikuje te same dane,
- proces może jednocześnie obsługiwać wiele rekordów,
- rozwiązanie wymaga rozbudowanej integracji,
- proces zawiera dużą liczbę wyjątków,
- nie określono sposobu obsługi błędów,
- nie wiadomo, kto będzie odpowiadał za utrzymanie rozwiązania.
Rozpoczęcie pracy bez wyjaśnienia tych kwestii może prowadzić do częstych zmian, konfliktów między automatyzacjami i rozwiązania, którego nikt nie chce później modyfikować.
W takiej sytuacji należy najpierw doprecyzować wymagania, odpowiedzialności oraz granice procesu.
Pięć zasad dobrego Flow Design
1. Zacznij od problemu
Nie rozpoczynaj od pytania: „Jak zbudować ten Flow?”. Najpierw zapytaj: „Jaki problem ma rozwiązać automatyzacja?”.
Dopiero gdy znasz problem, możesz właściwie dobrać narzędzie i strukturę rozwiązania.
2. Określ jeden wyraźny punkt startowy
Ustal, co uruchamia proces i w jakich warunkach powinien się rozpocząć.
Im dokładniej zdefiniujesz początek, tym łatwiej będzie kontrolować zachowanie automatyzacji.
3. Oddziel decyzje od działań
Najpierw ustal, jakie warunki należy sprawdzić. Następnie określ działania wykonywane dla poszczególnych wyników.
Dzięki temu logika będzie czytelniejsza i łatwiejsza do przetestowania.
4. Projektuj również ścieżkę niepowodzenia
Nie zakładaj, że wszystkie dane będą kompletne, a każda operacja zakończy się sukcesem.
Obsługa błędów powinna być częścią projektu, a nie poprawką dodawaną po wystąpieniu pierwszego problemu na środowisku produkcyjnym. Ustal z góry:
- co zobaczy użytkownik,
- jakie informacje zostaną zapisane,
- kto otrzyma powiadomienie,
- czy proces może zostać ponowiony.
5. Myśl o późniejszym utrzymaniu
Flow powinien być zrozumiały nie tylko dla osoby, która go stworzyła.
Czytelne nazewnictwo, logiczna struktura i ograniczenie niepotrzebnej złożoności są częścią dobrego projektu.
Osoba otwierająca automatyzację po kilku miesiącach powinna szybko rozpoznać:
- do czego służy Flow,
- kiedy jest uruchamiany,
- jakie dane wykorzystuje,
- jakie decyzje podejmuje,
- jakie działania wykonuje,
- jak reaguje na błędy.
Checklista przed rozpoczęciem budowy Flow
Proces
- Jaki problem rozwiązujemy?
- Kto uczestniczy w procesie?
- Co rozpoczyna proces?
- Jaki rezultat chcemy osiągnąć?
Dane
- Jakie dane są potrzebne?
- Gdzie znajdują się te dane?
- Czy mogą być niekompletne?
- Czy potrzebujemy informacji z rekordów powiązanych?
Logika
- Jakie decyzje musi podjąć system?
- Czy wszystkie warunki są jednoznaczne?
- Jakie są możliwe ścieżki procesu?
- Jakie wyjątki należy uwzględnić?
Działania
- Jakie operacje powinien wykonać system?
- Które rekordy zostaną utworzone lub zmienione?
- Czy inne automatyzacje mogą zareagować na te zmiany?
- Czy każde działanie jest rzeczywiście potrzebne?
Błędy
- Co może się nie udać?
- Co zobaczy użytkownik?
- Jak zapiszemy informacje o błędzie?
- Kto powinien zostać powiadomiony?
Jeżeli część odpowiedzi pozostaje niejasna, warto wrócić do analizy procesu przed rozpoczęciem implementacji.
Podsumowanie
Salesforce Flow pozwala automatyzować procesy działające na danych, reagować na zdarzenia, podejmować decyzje, wykonywać działania i prowadzić użytkowników przez kolejne etapy pracy.
Najważniejszą umiejętnością nie jest jednak samo korzystanie z Flow Buildera.
Dobry Flow zaczyna się od zrozumienia:
- problemu biznesowego,
- punktu uruchomienia,
- potrzebnych danych,
- reguł decyzyjnych,
- wykonywanych działań,
- oczekiwanego rezultatu,
- możliwych błędów.
Przed rozpoczęciem budowy spróbuj opisać proces jednym zdaniem:
Kiedy wydarzy się określone zdarzenie, system powinien sprawdzić potrzebne dane, podjąć decyzję i wykonać właściwe działanie.
Jeżeli potrafisz precyzyjnie uzupełnić każdą część tego zdania, masz podstawę do zaprojektowania automatyzacji.
Jeżeli nie, nie oznacza to jeszcze problemu z Flow. Najprawdopodobniej oznacza to, że sam proces wymaga dalszej analizy.
Sprawdź się
1. Od czego powinno zaczynać się projektowanie Flow?
Pokaż odpowiedź
Od zrozumienia procesu, a nie od narzędzia: co rozpoczyna proces, jakie dane są potrzebne, jakie warunki wpływają na jego przebieg, co ma zrobić system, jaki ma być rezultat i co się stanie w razie błędu.
2. Z jakich sześciu części składa się większość automatyzacji Flow?
Pokaż odpowiedź
Ze zdarzenia, danych, warunków, działań, rezultatu i obsługi błędu.
3. Kilka zespołów różnie opisuje oczekiwany rezultat procesu. Czy to dobry moment, żeby otworzyć Flow Builder?
Pokaż odpowiedź
Nie. Niejednoznaczne wymagania to sygnał, żeby najpierw doprecyzować proces, odpowiedzialności i jego granice. Budowa na niejasnych założeniach kończy się częstymi zmianami i konfliktami między automatyzacjami.
Następny krok: w kolejnej lekcji przyjrzysz się rodzajom Salesforce Flow i temu, jak wybrać właściwy typ automatyzacji na podstawie sposobu jej uruchomienia, potrzebnej interakcji z użytkownikiem i oczekiwanego rezultatu.



