Mentionsy Mentionsy
Coffee & Force - Polish Salesforce Podcast
Coffee & Force - Polish Salesforce Podcast

S02E22 - Go with the Flow – czyli Salesforce Flow na serio i z przymrużeniem oka - cz. II

21.09.2025 ·24 min 36 s

W drugiej części rozmowy z Mateuszem Twarożkiem i Krzysztofem Nowackim zagłębiamy się w temat, który jednych fascynuje, innych przeraża – Salesforce Flow. Autorzy nowej książki pokazują, że Flow można uczyć nie tylko skutecznie, ale też… z humorem.🎙️ Pytamy m.in.:dlaczego Flow stało się ich tematem numer jeden?czy naprawdę da się napisać podręcznik techniczny z żartami?czy Flow to przyszłość, czy tylko przystanek w stronę AI?„Flow to szansa, ale i odpowiedzialność. Można dużo zbudować, ale też wiele zepsuć.” – przyznają zgodnie obaj goście.Jeśli boisz się Flow – posłuchaj. Jeśli uwielbiasz Flow – też posłuchaj. A jeśli jeszcze nie wiesz, co to Flow… to ten odcinek jest dla Ciebie.🎧 Posłuchaj teraz i dowiedz się, dlaczego Flow to nie tylko funkcja w Salesforce, ale sposób myślenia o automatyzacji.#coffeeforce #SalesforceFlow #Automation #Trailblazer #Podcast #Salesforce #AdminLife #coffeeforcepodcast

Jak to z waszej perspektywy wygląda? Wiesz co, i tak i nie, bo pracując przez te dwa, trzy ostatnie lata jako Head of Admin CE widziałem, że jest bardzo duże rozgraniczenie w zależności od projektu. Mam gościa, który świetnie ogarnia swój projekt, który jest wyjątkowo mocno skustomizowany. Ja wiem doskonale, że na czystym Salesforce by to wyglądało zupełnie inaczej, ale on ogarnia tam od strony konfiguracyjnej, od strony userowej te rzeczy. Są inne osoby, które już mają na przykład deploymenty pod sobą. Wielokrotnie nie uważam, że np. admin powinien być odpowiedzialny za deployment, a mam również osoby, które do tej pory robią mega skomplikowane flowy. Mega skomplikowane flowy, które akurat to jest działka rekrutacyjna, w której wykonują mega skomplikowane akcje i ja jestem pełen chapeau bas, bo ja bym też wielokrotnie miał problem z takim mocno rozwiniętym flowem.

No, miałem doświadczenie z developerami, którzy dostali jakiś projekt, który był wycinkiem, musieli coś napisać, też nie przychodzili z Java czy, nie wiem, z czegoś tam jeszcze innego, z Pythona jakiegoś coś i jakby brakowało im potem tych core'owych tech i musieli szybko nadrabiać, jeżeli chcieli, oczywiście te dziury, więc to tak jak mówisz, trudno sobie wyobrazić, bo to w końcu czy prędzej jakby zaczniesz się koło na nowo pisać, jeżeli ci nie zna tych rzeczy. Dobra, pierwszą książkę mamy już zakończoną. Będziemy do samego procesu pisania książki jeszcze pewniej do kulis wracać. Przejdźmy sobie teraz do drugiej. Flow, potężne, olbrzymie narzędzie. Często też flowy są zmorą dla juniorów. No i pytanie, dlaczego akurat napisaliście książkę o flowach?

Skąd ten pomysł? Tak, to był mój pomysł, więc ja go sprzedałem Mateuszowi. Mateusz powiedział, dobra, mam chwilę czasu, to napisałem. Dwa dni miał to ok. Ja osobiście uważam, że Flow to jest taki game changer, naprawdę. Wiadomo, że żyjemy w takich czasach, że może żyjemy w etapie, kiedy to jest Blackberry w ogóle w Salesforce, że to zaraz będą prompty tylko i w ogóle... Ten flow, który znamy obecnie, to zniknie, ale to, co za nim stoi, zostanie. Czyli automatyzacja i robienie zaawansowanych automatyzacji uległa w Salesforceie demokratyzacji, że tak powiem, że łatwiejszy jest do tego dostęp i szybciej i łatwiej można rzeczy zrobić. Dla mnie to naprawdę jest game changer, a kiedy jakieś tam integracje, jakieś restywa weszły we flowach, to byłem w ogóle już zachwycony, że można sobie strzelić gdzieś do jakiejś zewnętrznej władzy, coś tam pozyskać, wypluć śmieszny dowcip na homescreenie dla handlowca, żeby zachęcić go do tego, żeby zupdateował okazję biznesową.

Więc z tego względu dla mnie, ja się jaram mocno flowami i z tego względu chciałem o tym coś napisać, tak? Żeby nam przerać tą wiedzę czy umiejętność, to co mnie zajarało tak naprawdę i zarazić kogoś innego. A ja powiem wam, że lubiłem proces Buildera. Nie było pątpliwości. Ja lubiłem proces Buildera i najgorsze jest to, że gdy już mi zakliknął tak bardzo dobrze, to nagle wtedy wskoczył flow i się poczułem jak dziecko we mgle. Ale tak jak Krzysiek powiedział, mega potężne narzędzie i robiące naprawdę dobrą robotę. Wielokrotnie dla ludzi, którzy są klientami, tak jak ja prowadziłem na przykład te quick starty, czyli te szybkie projekty i wskakiwali totalnie nieznający Salesforcea ludzie na spotkanie i w momencie, gdy im tłumaczyłem, że dla nas dzień po dniu używamy tej całej nomenklatury i starałem się im to bardzo obrazowo przedstawić i przedstawiałem, że coś się może zrobić samo,

To oni nie dowierzali albo wskakiwali z pomysłem, a słuchaj, a czy na przykład o tej i o tej porze może się wysłać mail? Tak, może, no niesamowite. Także myślę, że dla nich też jest coś niesamowitego i szczerze, jak czasami widzę w różnych use case'ach użycie tego Flow, w jaki sposób można go użyć, to jest naprawdę bardzo mało limitowane narzędzie i bardzo dużo pokazuje możliwości, jak go można użyć. Pewnie w jakiś flowach co mają 120 komponentów. Lubicie nasze rozmowy o Salesforce? Kliknijcie subskrybuj i bądźcie na bieżąco z każdym nowym odcinkiem. Twoja kolejna porcja inspiracji już w drodze. Dołącz do nas.

No właśnie, wiecie co, super, że ty mówisz, bo mam trochę wrażenie, że flowy są niedocenione, że często nawet jak osoby korzystają z flowów, to często to się kończy na trigger flowach albo na screen flowach i myślą, że już całą wiedzę o flowach mają. Więc jakbyśmy mogli teraz się troszkę zatrzymać i powiedzieć o tych różnych use case'ach i o potędze i możliwościach flowów. No tak, te rzeczy, które powiedziałeś, to są te główne rzeczy, które tak naprawdę się robi. Mamy jeszcze całą gamę innych rzeczy związanych z zapytaniem flowu na schedulery jakieś, które pozwalają zrobić coś w określonej godzinie czasu i tak dalej. Jakieś flowy, platform eventy, to są tematy bardziej takie już... Programistyczne. Mi się wydaje, że tutaj pewnie Salesforce nie powiedział jeszcze ostatniego słowa, bo nawet jeżeli chodzi o UI, UX i nazewnictwo tych rzeczy, to się zmienia.

W tematach bardziej integracyjnych częściej się stawia jednak Apex, bo jak znam te tematy, to one potrafią porosnąć do rangi większej rzeczy i myślę, że z tego względu ludzie się jeszcze boją pewne rzeczy we Flowach robić. Bo ta logika może być na tyle skomplikowana, że będzie to jakiś ślepy zaułek albo czegoś nie przewidzą, a mówi się, że w kodzie po prostu nie będzie tych limitów. W ogóle nie będziemy zaczynać dyskusji, czy Apex, czy Flow, bo to na to można nagrać półtora godziny podcast. Tak jest. Ale wiecie, nie chcę trochę odwracać swojego pytania, bo tak naprawdę rzeczywiście te record trigger flowy czy screen flowy to pewnie jest 80%, 90% tego, co się robi. Schedulerowe gdzieś tam są w jakiejś mniejszej procencie, a potem cała reszta, tak?

Może teraz approval proces, który też jest tak we Flowach zaawansowany, jakiś ten nowy, ale nawet jeszcze po tym nie klikałem za bardzo. Trudno mi odpowiedzieć na to pytanie w sumie w dużej mierze, bo trochę to jest związane z tym, kto tego najczęściej używa, a jak ktoś jest deweloperem, to jak ja znam deweloperów, to oni w ogóle nie chcą Flowów robić. Chyba, że w filmie jest przyjęty jakiś po prostu, jakaś zasada, że jeżeli chodzi o na przykład o to, że czy z, nie wiem, z jakimś prostym interfejsem to się zawsze idzie w screen flowy, a nie wiem, nie używa się record trigger flowów, tylko tam jest zawsze trigger fxowy. Różne są zasady, w różnych filmach pewnie się spotkałem i czasami one są takie po prostu, no ktoś tak założył. To może zadam inne pytanie. To taki twój ulubiony przypadek use case, gdzie użyłaś flowa i czułeś taką satysfakcję.

Poszło. Przypominasz sobie taką? Trochę. No, są takie flowy, które... No wiem, że masz setki, trzeba wybrać jeden, ale jest z tym problem, nie? Jakieś tematy fakturowe, księgowe, wysyłają rzeczy, tego typu tematy, update'ują coś regularnie raz w tygodniu czy raz w miesiącu, tego typu rzeczy. Wiele było takich. Ja najbardziej lubię screen flow'owe, które podsumowują jakieś nieoczywiste rzeczy z Salesforce'a, czyli zbierają do kupy pewne dane, wypływają go użytkownikowi, To są takie rzeczy, które mi się najbardziej podobają, bo one były kiedyś trudniej dostępne, a na pewno teraz są łatwe do zrobienia. U ich screenflowów jest o tyle teraz fajniejszy, że to jeszcze ciekawiej można pokazać niż takie, które było kiedyś w classicu.

Mi się wydaje, najbardziej lubię takie screen flowy, które zbierają dane z różnych rzeczy, z różnych miejsc i potrafią nam jakąś taką kartę klienta na przykład przedstawić, całościowy obraz, coś w jednym miejscu, tak. Tego typu rzeczy, nie wiem jak ty Mateusz. Wiecie co, dla mnie dwa tak de facto przypadki były dość proste, ale wielokrotnie ta prostota bardzo ratowała sprzedawców głównie, bo jedno to było flagowanie niepełnych rekordów na opportunities w stylu, gdy brakowało jakichś konkretnych kluczowych elementów. I nie mówiliśmy tutaj wtedy o blokowaniu całego rekordu Mandatory Fields, czy powiedzmy walidacjami, tylko szedł Scheduled Flow i weryfikował i wypluwał, flagował tak de facto rekordy, które należało uzupełnić. A drugi, stosunkowo prosty, ale też myślę, że mega przydatny, to było podmiana Record Type na Otwarty i Zablokowany.

Wiesz co, Flow były rewolucją w Salesforce, dalej są i pozwalają osobom nietechnicznym poczuć się jak programiści, tak? Ale czy to nie tworzy złudzenia, że każdy może wszystko, a później projekty wybuchają? Wiesz co, myślę, że przede wszystkim też jest kwestia doświadczenia. Ja osobiście jestem humanistą. Ja studiowałem w swoim życiu fizjoterapię i myślałem, że pójdę leczyć ludzi. Ale coś nie pykło. A piszesz książki. Tak, piszę książki, dokładnie i robię flowy, ale faktycznie daje to jakąś taką możliwość, natomiast to też nie przychodzi łatwo. Jako osoba totalnie, która gdyby nie miała w życiu kalkulatora, to byłbym zagubiony w tym świecie i powiedziała mi to moja pani od matematyki w technikum, więc jak najbardziej stwierdzam, że to musi być prawda. I myślę, że jest to kwestia na pewno doświadczenia, na pewno nie wrzucenie wszystkiego od razu na produkcję, tylko zweryfikowanie tego w swoim sandboxie, w swoim developer.org.

Najpierw weryfikacja, potem wdrożenie, testowanie i dopiero można z tym działać. I wtedy miejmy nadzieję, że coś nie wybuchnie. Na pewno muszę dodać, że mogę się poniekąd z tym, co powiedział Łukasz, zgodzić, ale tak naprawdę, jeżeli mamy przetestowane rzeczy, to będzie OK. Wiadomo, że test klasy nas w Apexie trochę ratują, ale jak wiemy test klasy w Apexie, to można napisać tak, żeby przeszła. Po prostu jeżeli jakieś testy nie pokryły tego materiału, tego wdrożenia poprawnie, no to nie mówię o testach programistów, tylko w ogóle, że ktoś to przetestował po prostu, to wszystko się wywali. Z flowami na pewno trzeba jakoś ostrożnie się nimi posługiwać, skorcić na pewno tworzenie ich na produkcji, tam siekanie, po prostu odpalanie i tam testowanie, co trzeba sobie starać się zabijać, na pewno.

Są zagrożenia, ale to według mnie jest więcej plusów niż tych zagrożeń. Projekty wybuchają według mnie i będą wybuchać. Widziałem takie, co wybuchały też przy Spaghetti Cold w Apexie, czy kurde nieostrożnym rzeczach na froncie, czy przepisywaniu Aury na LWC, a z LWC na coś jeszcze innego, albo mix przebojów, więc na pewno trzeba być ostrożnym, ale jak to mówi stare polskie przysłowie, wszystko jest dla ludzi. Tu myślę o tym, że możemy sobie nieskończenie tworzyć pewne rzeczy. Wiele różnych flow, do tego jeszcze dochodzą triggery apexowe, do tego validation rule'a i tak dalej i tak dalej. Performance kompletnie siada, już nie mówimy o błędach. Więc ta architektura jest dosyć dalej ważna i kluczowa w całości rozwiązania.

No i jest ważne. Dokładnie, tak, to masz rację, ale w Apexie też możesz pomieszczać różne rzeczy. Salesforce pozwala na taką kompozycję wielu tematów w jedno i to nie tylko jest we Flowach, ale można to robić w Apexie i trzeba na pewno pomyśleć i przemyśleć taką strategię, czy, nie wiem, walidacja się, kurde, polega na validation rule'ach, czy pewne rzeczy muszą być przeniesione gdzie indziej. Bo to musi być jednak walidacja we Flow i tak dalej, więc jakby to nie są proste rzeczy, dlatego rozumiem do czego pijesz. Pewnie jakby nie każdy powinien to od razu o tym decydować i czasami jest potrzebna jakaś szersza wiedza, żeby móc to zastosować poprawnie. To na pewno. Dokładnie tak. Dobra, wiesz co, we wstępie piszecie tak. Encyklopadie są w passe, a my chcemy dać praktykę i trochę żartów.

To mówię szczerze, że tak czasami mieliśmy, że tak powiem, pod górkę, ale nie pamiętam sytuacji, żebyśmy musieli wywalać jakiś dowcip specjalnie, bo byłby jakiś hardkorowy. Stawialiśmy na różnicę kulturową i podkreślaliśmy, że to jest zrozumiałe po prostu w naszym kręgu kulturowym i tego się trzymajmy. Mateusz na pewno ma część takich dowcipów, których nie rozumiem, bo przenosi je skąd, ile te twoje dzieciak, dziewczynka ma lat, to przenosi podstawówki czy... Dziewięciolatka tak, owszem. Tak, to jest pokolenie już inne, ja mogę nie czaić niektórych gier komputerowych, które teraz młodzież gra i skąd pochodzą pewne jakieś zwroty i dowcipy z tym związane, czy na przykład przykłady Flow, bo Mateusz przykłady Flow bazował na czym Toneka to gra, gangster, co to było, mafia, tak?

Pokazano wszystkie 15 dopasowań. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.