Salesforce Flow Summer ’26 upraszcza pracę admina

Decision z natywną obsługą dat, stabilniejsze deploymenty email templates i edycja screen flow z poziomu promptu – to zmiany, które skracają pracę we Flow Builderze już na etapie codziennej konfiguracji.

W praktyce chodzi nie o efektowne nowości, ale o usunięcie kilku punktów tarcia, które admini i konsultanci obchodzili formułami, ręcznymi poprawkami po deploymencie albo żmudnym klikaniem w builderze. Summer ’26 porządkuje właśnie te obszary. Dla zespołów utrzymujących wiele flow oznacza to mniej pracy technicznej dookoła automatyzacji i mniejsze ryzyko drobnych błędów konfiguracyjnych.

Logika dat i deploymenty przestają wymagać obejść

Najbardziej praktyczna zmiana dotyczy Decision elements. Gdy warunek korzysta z typu date, Flow Builder udostępnia teraz dedykowane operatory, takie jak Is Today, Is Anniversary of Today oraz Last Number of Days. Do tej pory podobne scenariusze wymagały formuł, nawet jeśli logika była prosta – na przykład sprawdzenie, czy kontrakt wygasa w ciągu 15 dni albo czy dziś wypada rocznica klienta.

To upraszcza sam projekt flow, ale też jego późniejsze utrzymanie. Mniej formuł oznacza mniej miejsc, w których logika biznesowa jest ukryta w składni zamiast być czytelna bezpośrednio w drzewie decyzji. Dla admina przejmującego cudzą automatyzację to realna oszczędność czasu podczas analizy błędów i zmian. Jeśli testujecie już nowości z release’u, dobrym uzupełnieniem będzie plan przeglądu innych funkcji administracyjnych opisanych w materiale o najważniejszych zmianach Summer ’26 dla adminów.

Druga istotna poprawka usuwa problem znany każdemu, kto przenosi flow między orgami. W Send Email action wybrany email template był wcześniej zapisywany jako ID powiązane z konkretnym orgiem. Po deploymencie do sandboxa albo produkcji referencja przestawała pasować i akcję trzeba było poprawiać ręcznie. W wersji 3.0.1 Send Email action zapisuje template jako referencję po nazwie, a nie po ID.

Operacyjnie oznacza to prostszy deployment i mniej poprawek po wdrożeniu. Żeby skorzystać z tej zmiany, trzeba zaktualizować Send Email action do wersji 3.0.1 i ponownie wybrać template z listy. To ważny detal – sama obecność nowej wersji nie rozwiąże problemu w istniejących flow bez ponownego zapisania referencji. Dla zespołów z pipeline’em release’owym to dobra okazja, by przejrzeć flow wykorzystujące maile i usunąć ręczne kroki z checklisty deploymentowej.

Screen Flow wchodzi w tryb edycji z promptu

Najgłośniejsza zmiana dotyczy screen flow, czyli tych procesów, które użytkownik faktycznie widzi i obsługuje. Agentforce panel pozwala teraz modyfikować także ten typ flow za pomocą opisu w języku naturalnym. Zamiast ręcznie dodawać pole, usuwać krok czy przestawiać elementy, można opisać oczekiwaną zmianę i zlecić jej wykonanie z poziomu panelu.

Mechanika ma kilka istotnych zabezpieczeń. Na czas przetwarzania instrukcji flow jest blokowany, więc zmiany nie powinny zostać przypadkowo nadpisane. Jeśli wynik nie jest zgodny z oczekiwaniem, można cofnąć ostatnią zmianę i spróbować innego opisu. Do uruchomienia tej funkcji potrzebne są Data 360 oraz włączone Einstein generative AI. To ważne z perspektywy planowania – nie jest to opcja dostępna automatycznie w każdym orgu.

Dla praktyka znaczenie tej funkcji zależy od typu pracy. Jeśli zespół często iteruje screen flow dla service, onboardingu albo procesów wewnętrznych, edycja z promptu może skrócić czas drobnych zmian i ograniczyć liczbę manualnych pomyłek. Jednocześnie warto traktować ją jako warstwę przyspieszającą konfigurację, a nie zastępującą review logiki. W orgach, które już budują kompetencje wokół Agentforce i Data 360, pomocny będzie szerszy kontekst z analizy tego, jak rozwija się roadmapa Agentforce oraz z omówienia roli Data 360 w praktycznych wdrożeniach AI.

Mniej tarcia w builderze: resource picker i panel walidacji

Pozostałe dwie zmiany nie przebudowują sposobu modelowania flow, ale poprawiają ergonomię pracy. W template-triggered prompt flows przeprojektowano resource picker dostępny w Add Prompt Instructions. Zasoby są teraz grupowane logicznie, mają czytelne etykiety i osobne ikony, a breadcrumb pokazuje, gdzie dokładnie znajduje się użytkownik w strukturze wyboru. Pojawia się też przycisk New Resource oraz podgląd dodatkowych informacji po najechaniu kursorem.

To typ ulepszenia, który łatwo zignorować w release notes, a trudno przecenić przy większych implementacjach. Gdy flow korzysta z wielu zasobów, szybkie odnalezienie właściwej zmiennej albo referencji skraca mikroczynności, które sumują się w godziny pracy miesięcznie. Szczególnie odczują to osoby budujące prompt flows częściej niż okazjonalnie.

Ostatnia zmiana dotyczy validation panel. W draft flow panel nie otwiera się już automatycznie po wejściu do Flow Buildera. Domyślnie pozostaje zamknięty, więc można najpierw skupić się na budowie lub poprawce konkretnego fragmentu procesu, a dopiero potem przejść do listy błędów i ostrzeżeń. Po otwarciu panelu problemy są prezentowane w kartach pogrupowanych według elementów, a kliknięcie prowadzi bezpośrednio do property panel właściwego elementu.

To drobna korekta, ale dobrze trafia w realny sposób pracy nad flow. Draft niemal zawsze ma ostrzeżenia lub błędy na którymś etapie tworzenia, więc automatyczne otwieranie walidacji bardziej przerywało pracę, niż pomagało. Nowy układ wspiera naturalną kolejność: najpierw budowa, potem kontrola jakości. W zespołach z dużą liczbą automatyzacji warto połączyć tę zmianę z regularnym przeglądem jakości danych i reguł walidacyjnych, bo to one często decydują, czy flow działa stabilnie poza środowiskiem testowym.

Summer ’26 nie zmienia Flow Buildera przez jedną wielką funkcję, tylko przez serię trafnych poprawek w miejscach, gdzie praca była najbardziej niewygodna. Najwięcej zyskają zespoły, które utrzymują istniejące flow i regularnie wdrażają zmiany między orgami. Którą z tych aktualizacji wdrożycie najpierw – natywne operatory dat, poprawiony deployment emaili czy edycję screen flow z poziomu promptu?