Salesforce Summer ’26 preview orgs: co testować teraz

16 kwietnia ruszają zapisy do preview orgs dla Summer ’26, a część użytkowników z wcześniejszym dostępem już może sprawdzać nowe funkcje przed wdrożeniem do produkcji. Dla zespołów pracujących na Salesforce to moment, w którym da się ocenić realny wpływ zmian na Flow, administrację uprawnieniami i codzienną pracę w Setup. Najwięcej sygnałów dotyczy teraz nie wielkich przebudów platformy, ale usprawnień, które mogą skrócić czas budowy automatyzacji i uprościć utrzymanie orga. To ważne szczególnie tam, gdzie admini i developerzy równolegle rozwijają procesy i muszą szybko ocenić, co warto wpisać do backlogu na kolejny release.

Preview orgs Summer ’26 – co już widać i dlaczego to ważne

Summer ’26 to wczesny etap cyklu wydawniczego, w którym preview orgs zaczynają udostępniać nowe funkcje jeszcze przed wejściem zmian na produkcję. Rejestracja ma ruszyć 16 kwietnia, a oficjalne release notes są zapowiedziane na 22 kwietnia. Z perspektywy praktyka najważniejsze jest to, że część funkcji można ocenić wcześniej i przygotować listę testów regresji, zamiast czekać na pełny rollout.

Najwięcej zmian dotyczy dziś Flow. Wśród nich pojawia się powrót usprawnień dla Lookupów w komponencie Data Table dla Flow. Wcześniej, jak opisuje autor, trzeba było budować własne obejścia oparte o URL, aby pokazać nazwę rekordu i umożliwić przejście do niego po kliknięciu. W Summer ’26 ma być dostępny prostszy wariant oparty o checkbox, który wyświetla nazwę rekordu i przekierowuje użytkownika do szczegółów. To mała zmiana interfejsowa, ale w praktyce usuwa ręczne obejścia i zmniejsza liczbę niestandardowych rozwiązań w Screen Flow.

Drugi obszar to nowy komponent Radio Button Group w Screen Flow. Autor zestawia go z klasycznymi Radio Buttons i wskazuje przede wszystkim na lepszą estetykę oraz mniejsze zużycie miejsca na ekranie. Dla zespołów budujących formularze wewnętrzne albo guided flows oznacza to prostsze projektowanie ekranów bez konieczności szukania niestandardowych komponentów tylko po to, by poprawić UX.

Do tego dochodzi wizualne uporządkowanie błędów i ostrzeżeń w Flow Builderze oraz możliwość zwijania Fault Paths. Ta druga zmiana może mieć praktyczne znaczenie w bardziej rozbudowanych flow, gdzie wiele ścieżek błędów prowadzi do jednego subflow obsługującego wyjątki. Mniej przeładowany canvas to szybsza analiza logiki i łatwiejszy przegląd automatyzacji podczas code review albo troubleshootingu.

Jeśli Wasz zespół traktuje Flow jako główną warstwę automatyzacji, dobrym kontekstem jest też wcześniejsza zmiana opisana w Coffeeforce, gdzie Flow Orchestration stał się standardowym typem flow. Summer ’26 nie zmienia tu samego modelu automatyzacji, ale dalej poprawia ergonomię pracy z builderem i komponentami.

Co z tym zrobić teraz? Najprościej przygotować krótką listę scenariuszy testowych dla Screen Flow: ekrany z Lookupami, formularze z Radio Buttons oraz flow z rozbudowaną obsługą błędów. W preview orgu warto sprawdzić nie tylko to, czy funkcje działają, ale też czy można dzięki nim usunąć istniejące obejścia, komponenty customowe albo nadmiarową logikę pomocniczą.

Flow Builder dostaje drobne zmiany, które oszczędzają czas

Najciekawszą zmianą operacyjną po stronie automatyzacji jest możliwość ograniczania maksymalnego batch size w Schedule-Triggered Flows. Według źródła daje to builderom większą kontrolę nad automatyzacją i pomaga ograniczyć problemy wtedy, gdy kryteria wejścia spełni więcej rekordów, niż zakładano. To nie jest pełny odpowiednik mechanizmów znanych z Batch Apex (przetwarzanie asynchroniczne rekordów w partiach), ale kierunek jest jasny: większa przewidywalność wykonania flow uruchamianych harmonogramem.

Dla praktyka oznacza to bardziej świadome zarządzanie ryzykiem wydajnościowym. Jeśli Scheduled Flow obsługuje rekordy o zmiennej skali, możliwość ograniczenia partii może pomóc uniknąć sytuacji, w której jeden źle oszacowany warunek uruchamia zbyt ciężkie przetwarzanie. To szczególnie ważne w orgach, gdzie flow przejęły zadania, które wcześniej realizował Apex.

Warto zestawić to z podejściem do harmonogramów po stronie kodu. Jeśli w zespole równolegle występują Scheduled Flows i Scheduled Apex, przydatnym uzupełnieniem będzie materiał o tym, jak działa warstwa CRON w Scheduled Apex. Nie dlatego, że źródło sugeruje migrację między narzędziami, ale dlatego, że Summer ’26 wzmacnia potrzebę świadomego wyboru między low-code a kodem tam, gdzie liczy się kontrola nad skalą wykonania.

Źródło wspomina też o Global Flow Resources, które wydają się umożliwiać tworzenie zmiennych dostępnych w wielu flow, choć funkcja ma być jeszcze częściowo wdrożona i nie w pełni działać. To ważne zastrzeżenie. Na tym etapie nie warto planować przebudowy architektury flow pod tę funkcję, ale zdecydowanie warto ją obserwować. Jeśli dojrzeje, może uprościć zarządzanie wspólnymi wartościami wykorzystywanymi w różnych automatyzacjach.

Podobnie należy traktować komponent AI Content Summarizer w Lightning App Builderze. Autor zauważa, że komponent jest widoczny, można go umieścić na stronie Lightning, ale obecnie nie robi jeszcze zbyt wiele. To sygnał do monitorowania, nie do wdrożenia. W polskich zespołach sensowna praktyka będzie tu prosta: odnotować funkcję, ale nie wpisywać jej jeszcze do planu produkcyjnego bez dodatkowych informacji z release notes.

Jeśli Wasz zespół już testuje nowe sposoby budowy na platformie, ciekawym kontekstem jest też analiza, jak Agentforce Vibes zmienia pracę adminów przy tworzeniu aplikacji. W obu przypadkach wspólny mianownik jest ten sam: mniej ręcznych obejść, więcej nacisku na szybkość budowy i utrzymanie jakości konfiguracji.

Nie tylko Flow – zmiany dla adminów w Setup i interfejsie

Summer ’26 przynosi też kilka nowości stricte administracyjnych. Jedna z nich to nowy toggle na stronie User Interface w Setup, który pozwala uczynić współdzielone list views edytowalnymi. Zgodnie ze źródłem użytkownicy, którym udostępniono list view, będą mogli je modyfikować, o ile mają uprawnienie Create and Customize List Views. Dla admina to zmiana w modelu odpowiedzialności za konfigurację list – większa elastyczność dla biznesu, ale też potrzeba pilnowania, kto realnie może zmieniać współdzielone widoki.

Jak to działa w praktyce? Samo współdzielenie list view nie wystarczy. Nadal potrzebne jest odpowiednie uprawnienie. To oznacza, że funkcja nie znosi kontroli dostępu, tylko przesuwa granicę między centralnym zarządzaniem a samoobsługą użytkowników. W orgach z dużą liczbą zespołów sprzedażowych albo operacyjnych może to ograniczyć liczbę drobnych ticketów do admina. Z drugiej strony warto wcześniej ustalić zasady nazewnictwa i właścicielstwa współdzielonych widoków.

Kolejna zmiana to nowa zakładka Field Access w Object Managerze. Źródło opisuje ją jako interfejs pokazujący pola danego obiektu wraz z informacją, jak został przyznany dostęp. To może zastąpić starszy, profilowy widok field accessibility. Dla adminów i konsultantów zajmujących się bezpieczeństwem modelu danych to potencjalnie duże uproszczenie diagnostyki uprawnień na poziomie pola.

Wspomniany jest także Dark Mode dla większej liczby orgów, choć autor zaznacza niepewność i możliwość korekty po aktualizacjach sandboxów. To dobry przykład funkcji, którą należy traktować ostrożnie: przydatna dla komfortu użytkowników, ale jeszcze niepotwierdzona jako szeroko dostępna zmiana. Jeśli pojawi się w Waszym preview orgu, warto to sprawdzić i przygotować komunikację dla użytkowników, ale bez założenia, że funkcja na pewno będzie dostępna identycznie we wszystkich środowiskach.

Na marginesie źródło wspomina też o Web Console w becie od 14 kwietnia, zaznaczając, że formalnie nie jest to funkcja Summer ’26. To ważne rozróżnienie. Dla developerów może to być istotny kierunek, ale w tym materiale najwięcej konkretu jest po stronie Flow i Setup, więc właśnie tam warto zacząć testy.

ZAKOŃCZENIE

Summer ’26 na obecnym etapie wygląda przede wszystkim jak release porządkujący codzienną pracę z Flow i administracją interfejsem, a nie jak zestaw jednej dominującej nowości. Dla polskich zespołów najrozsądniejsza strategia to szybkie testy w preview orgach, identyfikacja funkcji usuwających lokalne obejścia i wstrzymanie się z decyzjami tam, gdzie funkcje są jeszcze niepełne. Oficjalne release notes 22 kwietnia powinny doprecyzować, co faktycznie trafi do szerokiego użycia. Którą z tych zmian najpierw sprawdzicie w swoim orgu – ergonomię Flow Buildera, kontrolę batch size czy nowe widoki administracyjne?