Before-Save czy After-Save w Salesforce Flow?

Tworzysz Record-Triggered Flow. Wiesz już, jaki rekord uruchamia automatyzację i jaki rezultat chcesz osiągnąć.

Pozostaje jednak ważna decyzja:

Czy Flow powinien wykonać się przed zapisaniem rekordu, czy dopiero po jego zapisaniu?

Wybór pomiędzy Before-Save i After-Save zależy przede wszystkim od tego, co automatyzacja ma zrobić.

Before-Save czy After-Save: na czym polega różnica?

Wyobraź sobie następujące wymaganie:

Po utworzeniu zgłoszenia dla strategicznego klienta system powinien ustawić wysoki priorytet i utworzyć zadanie dla zespołu obsługi.

Mamy jedno zdarzenie, czyli utworzenie zgłoszenia, ale dwa różne działania:

1. ustawienie priorytetu na tworzonym zgłoszeniu,
2. utworzenie powiązanego zadania.

Pierwsze działanie zmienia pola rekordu, który jest właśnie zapisywany. Drugie tworzy nowy rekord po zapisaniu zgłoszenia.

Chcesz zmienić pola na zapisywanym rekordzie? Najpierw rozważ Before-Save.

Chcesz utworzyć inny rekord, zaktualizować powiązane dane lub rozpocząć kolejny proces? Rozważ After-Save.

Kiedy użyć Before-Save Flow?

Before-Save wykonuje logikę przed zakończeniem operacji zapisu. W Flow Builderze ten wariant jest określany jako Fast Field Updates.

Jego głównym zadaniem jest przygotowanie pól rekordu, który uruchomił proces.

Before-Save warto rozważyć, gdy Flow ma:

• ustawić wartość pola,
• uzupełnić brakującą informację,
• obliczyć klasyfikację,
• znormalizować dane,
• wyznaczyć wewnętrzny status,
• ustawić wartość domyślną.

Przykład: ustawienie priorytetu zgłoszenia

Jeżeli klient strategiczny zgłasza awarię objętą określonym poziomem SLA, system powinien ustawić wysoki priorytet.

Flow może:

1. sprawdzić typ klienta,
2. odczytać kategorię zgłoszenia,
3. zweryfikować warunki,
4. ustawić priorytet,
5. zapisać rekord z właściwą wartością.

Nie tworzymy dodatkowych rekordów i nie zmieniamy innych danych. Pracujemy wyłącznie na zgłoszeniu, które uruchomiło proces. Before-Save jest więc naturalnym wyborem.

Przykład: normalizacja danych

Użytkownicy mogą wpisywać numer telefonu ze spacjami, myślnikami lub różnymi prefiksami. Before-Save może przygotować ujednoliconą wartość i zapisać ją na rekordzie jeszcze przed zakończeniem operacji.

Podobne rozwiązanie można zastosować do ustawienia regionu, przypisania kategorii, obliczenia klasyfikacji Opportunity lub uzupełnienia wartości domyślnej.

Jak myśleć o Before-Save?

Czego nie należy robić w Before-Save?

Before-Save nie jest właściwym wyborem, jeżeli głównym celem procesu jest:

• utworzenie zadania,
• utworzenie rekordu powiązanego,
• aktualizacja innego rekordu,
• wykonanie działania wymagającego zapisanego rekordu,
• rozpoczęcie szerszego procesu biznesowego.

Częstym błędem jest próba umieszczenia całej logiki w Before-Save tylko dlatego, że ten wariant kojarzy się z lepszą wydajnością.

Czy ta logika przygotowuje pola rekordu, który jest właśnie zapisywany?

Jeżeli odpowiedź brzmi „nie”, rozważ After-Save albo podział procesu.

Kiedy użyć After-Save Flow?

After-Save wykonuje logikę po zapisaniu rekordu.

Ten wariant wykorzystujemy, gdy automatyzacja ma:

• utworzyć zadanie,
• utworzyć rekord powiązany,
• zaktualizować inny rekord,
• wykonać dodatkowe działanie,
• rozpocząć kolejny etap procesu,
• uruchomić dalszą automatyzację.

Czy działanie wykracza poza zmianę pól rekordu uruchamiającego?

Przykład: utworzenie zadania

Po zapisaniu zgłoszenia o wysokim priorytecie system powinien utworzyć zadanie dla właściciela.

1. sprawdzenie priorytetu zgłoszenia,
2. określenie właściciela zadania,
3. wyznaczenie terminu,
4. utworzenie Task,
5. powiązanie zadania ze zgłoszeniem.

Zadanie jest osobnym rekordem, dlatego proces powinien wykonać się po zapisaniu zgłoszenia.

Przykład: wygrana sprzedaż

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

Automatyzacja rozpoczyna nowy proces biznesowy, dlatego After-Save odpowiada charakterowi tego wymagania.

Jak myśleć o After-Save?

Czy After-Save powinien aktualizować rekord uruchamiający?

After-Save może ponownie zaktualizować rekord, który uruchomił proces. Zawsze warto jednak sprawdzić, czy taka aktualizacja jest konieczna.

Jeżeli jedynym celem Flow jest ustawienie kategorii lub innego pola na zapisywanym rekordzie, Before-Save będzie zwykle bardziej naturalnym kandydatem.

Ponowna aktualizacja w After-Save może:

• uruchomić inne automatyzacje,
• spowodować kolejne wykonanie Flow,
• zwiększyć liczbę operacji,
• utrudnić analizę procesu,
• doprowadzić do konfliktu z inną logiką.

Jeżeli jedynym rezultatem jest zmiana pól rekordu uruchamiającego, najpierw sprawdź Before-Save.

Jeden proces, dwa Flow

Jeden proces biznesowy może wymagać zarówno Before-Save, jak i After-Save.

W przypadku zgłoszenia klienta strategicznego naturalny podział może wyglądać następująco:

Before-Save

• ustawia priorytet,
• uzupełnia kategorię,
• przygotowuje dane na rekordzie.

After-Save

• tworzy zadanie,
• aktualizuje inne rekordy,
• rozpoczyna dalszy proces.

Dwa Flow nie muszą oznaczać większego chaosu. Jeżeli każdy z nich ma wyraźną odpowiedzialność, taki podział może poprawić czytelność rozwiązania.

Nie należy jednak dzielić każdego procesu automatycznie. Jeżeli wymaganie obejmuje wyłącznie zmianę pól, wystarczy Before-Save. Jeżeli obejmuje tylko działania po zapisie, wystarczy After-Save.

Before-Save vs After-Save: szybkie porównanie

Pytanie	Before-Save	After-Save
Kiedy działa?	Przed zapisem	Po zapisie
Główny cel	Przygotowanie pól rekordu	Dalsze działania
Zmiana rekordu uruchamiającego	Tak	Możliwa, ale wymaga oceny
Tworzenie innych rekordów	Nie	Tak
Aktualizacja powiązanych danych	Nie	Tak
Tworzenie zadań	Nie	Tak
Rozpoczęcie kolejnego procesu	Nie	Tak

Jak wybrać właściwy wariant?

Co ma wykonać Flow?	Wariant
Zmienić pola na zapisywanym rekordzie	Before-Save
Utworzyć rekord powiązany	After-Save
Zaktualizować inny rekord	After-Save
Utworzyć zadanie lub wykonać dalsze działanie	After-Save
Wykonać oba rodzaje operacji	rozważ podział procesu

To punkt wyjścia, a nie zamiennik analizy procesu.

Nie zapominaj o warunkach uruchomienia

Sam wybór Before-Save albo After-Save nie wystarczy.

Załóżmy, że Flow powinien uruchomić się, gdy status zgłoszenia zmieni się z „Nowe” na „W trakcie”. Warunek „Status równa się W trakcie” może być spełniony również podczas kolejnych edycji rekordu, mimo że status już się nie zmienia.

Trzeba więc rozróżnić dwa wymagania:

• uruchom proces, kiedy status ma określoną wartość,
• uruchom proces, kiedy status właśnie zmienił się na określoną wartość.

Ta różnica decyduje, czy Flow wykona się raz, czy przy kolejnych aktualizacjach rekordu.

W Flow Builderze drugie wymaganie ustawisz w konfiguracji startu Flow, wybierając dla aktualizowanych rekordów opcję Only when a record is updated to meet the condition requirements.

Najczęstsze błędy

Użycie After-Save do prostej zmiany pola

Jeżeli proces jedynie ustawia wartość na rekordzie uruchamiającym, najpierw rozważ Before-Save.

Próba wykonania wszystkiego w Before-Save

Before-Save służy przede wszystkim do przygotowania zapisywanego rekordu, a nie do obsługi całego procesu biznesowego.

Brak podziału odpowiedzialności

Jeden Flow próbuje jednocześnie zmieniać pola, tworzyć rekordy, wysyłać powiadomienia i uruchamiać integrację.

Nieprecyzyjne warunki uruchomienia

Flow wykonuje się przy każdej edycji rekordu, mimo że powinien reagować tylko na konkretną zmianę.

Ponowna aktualizacja bez kontroli

After-Save aktualizuje rekord uruchamiający i przypadkowo uruchamia inne automatyzacje.

Checklista przed utworzeniem Flow

1. Czy zmieniam wyłącznie pola rekordu uruchamiającego?
2. Czy tworzę lub aktualizuję inne rekordy?
3. Czy działanie wymaga zapisanego rekordu?
4. Czy proces obejmuje dwie różne odpowiedzialności?
5. Czy warunki uruchomienia reagują na właściwą zmianę?

Jeżeli zmieniasz tylko pola bieżącego rekordu, zacznij od oceny Before-Save. Jeżeli wykonujesz działania na innych danych, rozważ After-Save. Jeżeli robisz jedno i drugie, oceń zasadność podziału procesu.

Podsumowanie: Before-Save czy After-Save?

Before-Save i After-Save nie są konkurencyjnymi sposobami budowania tego samego Flow. Każdy wariant ma inną odpowiedzialność.

Before-Save przygotowuje rekord przed zapisem.

After-Save wykonuje działania wynikające z zapisu rekordu.

Chcesz zmienić pola na zapisywanym rekordzie? Rozważ Before-Save.

Chcesz utworzyć rekord, zmienić inne dane lub rozpocząć kolejny proces? Rozważ After-Save.

Przed rozpoczęciem budowy uzupełnij zdanie:

Przed zapisaniem rekordu system powinien __________, a po jego zapisaniu powinien __________.

Jeżeli pierwsza część dotyczy pól rekordu, a druga dalszych działań, prawdopodobnie masz już naturalny podział automatyzacji.

Sprawdź się

1. Flow ma tylko ujednolicić format numeru telefonu na zapisywanym kontakcie. Który wariant wybierzesz?

Pokaż odpowiedź

Before-Save (Fast Field Updates). Zmieniasz wyłącznie pole rekordu, który uruchomił proces, i nie tworzysz innych rekordów.

2. Po wygraniu szansy sprzedaży trzeba utworzyć projekt wdrożeniowy i zadania. Dlaczego nie Before-Save?

Pokaż odpowiedź

Bo działania wykraczają poza zmianę pól rekordu uruchamiającego: powstają nowe rekordy. To zadanie dla After-Save.

3. Flow ma się wykonać, gdy status zmienia się na „W trakcie”, a wykonuje się przy każdej edycji zgłoszenia. Co jest nie tak?

Pokaż odpowiedź

Warunek sprawdza, czy status ma określoną wartość, a nie czy właśnie się na nią zmienił. Trzeba ustawić uruchamianie tylko wtedy, gdy rekord zostaje zaktualizowany tak, że zaczyna spełniać warunki.

Następny krok: w ostatniej lekcji kursu zbudujesz swój pierwszy Record-Triggered Flow krok po kroku i wybierzesz dla niego właściwy wariant.