Workflows

Workflow łączy kroki w automatyzację, którą wykonują Twoje agenty: odczytać tabelę, wywołać agenta, rozgałęzić się na podstawie wyniku, przejść w pętli po liście. Budujesz go na kanwie, łączysz kroki ze sobą i publikujesz jako niezmienną wersję — to ten sam kształt, który ma agent: draft, który edytujesz, i opublikowana wersja, która działa.

Ta strona opisuje edytor wizualny: listę, kanwę i wybór kroków, sposób konfiguracji węzła, autozapis i publikowanie oraz drogi klawiaturowe przez to wszystko. Edytor znajduje się w sekcji Workflows w konsoli. Strona listy Workflows ma "?", które odtwarza przewodnik po tej liście; sam edytor nie ma przewodnika.

Tworzenie i duplikowanie workflow

New workflow wymaga nazwy i wyboru odbiorców, tak jak tworzenie agenta: wszyscy, tylko Ty lub wybrane osoby i działy. Wybierz wyzwalacz, opcjonalnie dodaj opis i tagi, a następnie kliknij Create. Sam wybór wyzwalacza nie tworzy workflow. Workflow templates otwiera osobną galerię kategorii; wybranie szablonu otwiera ten formularz z uzupełnioną nazwą i opisem.

Katalog trzyma karty i wyszukiwanie we wspólnym panelu. Filters odsłania status, tagi i sortowanie oraz pokazuje liczbę aktywnych filtrów. Nieudane pobranie danych daje Retry zamiast pustego katalogu. Import zaczyna się od wyboru pliku; Or paste the file's JSON here odsłania pole tekstowe z etykietą.

Lista pokazuje każdy workflow, który widzisz, jako kartę: jego status, kto może do niego dotrzeć, czy ma żywą wersję i kiedy ostatnio go edytowano. Filter by status zawęża ją do Drafts, które wciąż budujesz, Published, które działają, albo Archived. Z karty otwierasz edytor, runy workflow albo kopię.

Duplicate kopiuje bieżący draft workflow do nowego o nazwie {name} (copy). Duplikat to nowy workflow z własnym draftem, nigdy kopia opublikowanej wersji.

Pusta lista może być filtrem, a nie pustą organizacją

No workflows yet i Nothing matches to różne stany: pierwszy to organizacja bez żadnego workflow, drugi to filtr statusu, pod który nie wpada żaden wiersz. Clear filter przywraca pełną listę. Workflow udostępniony Tobie pojawia się na tej samej liście, gdy masz workflows:view.

Szablony, eksport i import

Gotowe automatyzacje to Publiczne API → tabela i Notatnik Markdown. Serwer w jednej transakcji przygotowuje tabelę i kompletnie skonfigurowany szkic. Domyślnie są prywatne; jawnie wybrani odbiorcy dotyczą workflow i jego tabeli. Nie trzeba wybierać konta, klucza API ani tabeli. Pierwszy przykład pobiera wpis z JSONPlaceholder i zapisuje tytuł oraz treść; drugi zapisuje notatkę Markdown. Kolejne runy używają tej samej tabeli i aktualizują ten sam przykładowy rekord. Utworzenie wymaga uprawnień do tworzenia i edycji tabel. Starter i Two-step sequence pozostają małymi lokalnymi przykładami.

Historia uruchomień domyślnie wypełnia dostępną przestrzeń strony, bez przycisku rozszerzania. Katalog wypełnia dostępną wysokość strony i ma własny przycisk pełnego ekranu. Paginacja pojawia się dopiero przy kolejnej stronie. Import ma opisany obszar wyboru pliku, który przyjmuje też upuszczony plik JSON.

Paginacja historii uruchomień jest na dole panelu. Szczegóły runu mają zwarty pasek podsumowania, canvas wypełniającą obszar pracy oraz jeden panel boczny z krokami, wynikiem i dostępnymi plikami. Kliknięcie kroku otwiera jego zapisane dane. Import pliku i wklejanie JSON mają osobne zakładki; JSON ma pole kodu i formatowanie, które zgłasza błąd bez usuwania treści.

Export workflow w menu More w nagłówku edytora eksportuje szkic jako plik .workflow.json. Plik nie zawiera żadnych identyfikatorów tego wdrożenia: każdy agent, tabela, sekret, członek, bot czy workflow wybrany w kroku zostaje pominięty i wymieniony, przypięte dane testowe też, podobnie jak workflow błędów. Nigdy nie zawiera wartości sekretu. Import na liście tworzy z takiego pliku nowy szkic, usuwa identyfikatory, które plik zrobiony ręcznie jeszcze zawiera, i wymienia każdy krok i pole do ponownego wybrania przed publikacją. Plik z krokiem, którego to wdrożenie nie ma, zostaje odrzucony i nic nie powstaje.

Wyszukiwanie, nazywanie i wycofywanie workflow

Każda karta mówi, co uruchamia workflow i ile ma kroków, czy jest aktywny, czy to szkic, oraz jak i kiedy poszedł jego ostatni przebieg - do pierwszego przebiegu datę edycji.

Nad kartami wyszukiwanie znajduje workflow po nazwie, opisie lub tagach, filtr tagów zawęża listę do jednego tagu, a kolejność to ostatnia edycja, nazwa albo najnowsze najpierw. Wszystko zostaje w adresie, więc przeładowanie lub udostępniony link pokazują tę samą listę.

More → Settings zawiera nazwę, opis, tagi i ustawienia wykonania workflow, zapisywane automatycznie. Edytor kroku wypełnia dostępne okno: Input po lewej, Parameters i Settings pośrodku, Output po prawej. Wyzwalacze mają dwa panele, bo nie odbierają danych z poprzednich kroków. Na dużym ekranie panele przewijają się osobno, a na telefonie tworzą jedną przewijaną kolumnę. Zapisane wykonanie pokazuje parametry tylko do odczytu obok danych. Wartości rekordu mają pola nazwane według kolumn tabeli. Notatki oferują Open note, gotowe rozmiary i uchwyty zmiany rozmiaru.

Picker aplikacji pokazuje serwery z katalogu MCP także przed połączeniem; ogólna pozycja Call an MCP tool jest ukryta. Połącz usługę na miejscu, a następnie wybierz wykryte narzędzie. Lista dozwolonych narzędzi połączenia nadal obowiązuje. Kanwa domyślnie pokazuje kolorowe kroki i minimapę. Kroki modeli AI odsłaniają instrukcje, temperaturę i effort; puste ustawienia zachowują domyślne wartości dostawcy. Decyzje Jev pokazują model, pytanie i próg pewności. Send an email używa nadawcy platformy albo łączy Gmail lub Outlook i po potwierdzeniu zmienia krok na rzeczywiste narzędzie MCP tej skrzynki. Zmiana usuwa niezgodne mapowania wejścia i można ją cofnąć.

Krok Send an email oferuje też SMTP account → Nowe konto SMTP. W formularzu vault podaj serwer, port, login, hasło i nadawcę. STARTTLS zwykle korzysta z 587, a implicit TLS z 465; oba tryby weryfikują certyfikat. Workflow zapisuje tylko smtp_secret_id. Opcja Nadawca platformy usuwa wybór. Publikacja i wykonanie sprawdzają dostęp do sekretu; niedostępne konto zatrzymuje krok zamiast zmieniać nadawcę.

HTTP request, upload i download mają wspólny panel Uwierzytelnianie: brak, Bearer, klucz API w nagłówku, klucz API w parametrze URL albo Basic Auth. Wybierz istniejące HTTP credential z vault lub utwórz je w kroku; dozwolony adres API jest podpowiadany na podstawie URL. Workflow zapisuje tylko auth.secret_id. Własna nazwa nagłówka i opcjonalny prefiks obsługują np. Authorization: Token …. Basic Auth używa nazwy użytkownika i tokenu z vault jako loginu i hasła. Zmiana metody usuwa nieaktualne ustawienia, zachowując referencję; wyłączenie uwierzytelniania usuwa też referencję.

Wyszukiwanie aplikacji obejmuje też lustrzany rejestr MCP, także niepodłączone usługi. Podłączony serwer bez listy narzędzi udostępnia administratorom połączeń Refresh tools. Kroki kanałów pozwalają utworzyć i wybrać konto bota bez opuszczania workflow; przycisk widzą tylko osoby z prawem zarządzania kanałami.

Architect potrafi poznać katalog kroków, tworzyć i zmieniać prywatne szkice workflows, testować je oraz sprawdzać wyniki runów. Tworzy też typowane Virtual Tables oraz wyszukuje i aktualizuje rekordy. Skille workflow-builder i virtual-tables wyjaśniają, kiedy używać tych funkcji. Jeśli usługi nie ma w galerii MCP, Architect może opakować jej udokumentowane API krokiem HTTP request i udostępnić opublikowany workflow jako narzędzie agenta przez narzędzia AgenticOS MCP. Poświadczenia pozostają w sejfie. Testy mogą wykonywać rzeczywiste działania; publikacja zachowująca uprawnienia człowieka nadal wymaga jego sesji.

Pod nazwą edytor mówi, na czym stoi workflow: Draft, not published albo Live · version 3, z Unpublished changes obok, gdy szkic różni się od tej wersji w sposób, który przeniosłaby publikacja. Przesunięcie kroku ani przypięcie danych testowych się nie liczy.

Opublikowany workflow, którego wyzwalacz działa sam - webhook, harmonogram lub nowy rekord tabeli - ma przełącznik Active w nagłówku edytora, a jego karta mówi Active albo Paused. Wyłączenie od razu wstrzymuje wyzwalacz; włączenie wznawia go jako publikującego, więc wymaga uprawnienia do uruchamiania workflow. Menu ... na karcie archiwizuje workflow, co również wstrzymuje wyzwalacz. Zarchiwizowany można przywrócić, nadal wstrzymany, albo usunąć razem z wersjami, przebiegami i udostępnieniami; taki, którego przebiegi się nie zakończyły, jest odrzucany z WORKFLOW_IN_USE.

Kroki agentów przechowują prywatne rozmowy dla historii modelu i przestrzeni roboczych o zakresie rozmowy. Kolejne wiadomości czatu korzystają z tego samego kontekstu kroku; widoczny czat otrzymuje tylko wynik workflow. Czaty testowe mają osobne sesje, a rozpoczęcie nowego czatu testowego resetuje kontekst. Rozmowy wewnętrzne nie pojawiają się na liście czatów i są usuwane wraz z workflow lub czatem źródłowym.

Agenci wywoływani z workflow mogą używać narzędzi AgenticOS MCP w workerze w tle, tak samo jak w czacie internetowym.

Kanwa i dodawanie kroków

Edytor pozostawia widoczne Runs, Test draft i Publish. More zawiera Versions i przełącznik edycji/podglądu. Canvas options mieści minimapę, styl połączeń i skróty. Krok bez połączenia wejściowego pomija pusty panel Input, zostawiając więcej miejsca na parametry; Expected output fields rozwija schemat wyjścia. Review setup before testing odsłania brakującą konfigurację.

Kanwa to miejsce, w którym pojawiają się kroki i połączenia workflow, i ma całą szerokość edytora pod nagłówkiem. Węzeł to jeden krok; krawędź to połączenie ustalające kolejność: krok, na który wskazuje, działa po tym, z którego wychodzi.

Każdy węzeł to karta z ikoną kroku, jego nazwą i jedną linią pod nią: co krok ma robić - warunek, URL, liczba zmapowanych pól - po agencie, modelu albo tabeli, z którymi pracuje. Krok z więcej niż jednym wyjściem wymienia porty z nazwy: true i false, Each item i Done oraz czerwony port Error w kroku, który obsługuje swoje błędy. Krok, który blokuje publikację, ma znacznik konfiguracji (czerwony po próbie testu lub publikacji): po najechaniu na niego widać pierwsze problemy, a kliknięcie otwiera krok.

Gładzik albo kółko myszy przesuwa kanwę, a gest szczypania - albo Ctrl lub Cmd z kółkiem - ją przybliża; jej przyciski są w rogu.

Kroki wybiera się w wyborze kroków. Pokazuje sekcje - Start, AI, Flow, Data, Apps and the web - z grupami pod każdą. Grupa taka jak Slack, Tables czy Jev decisions otwiera się na swoje kroki, a grupa z jednym krokiem jest tym krokiem. Search steps znajduje dowolny krok po nazwie, tym, co robi, albo po grupie. Krok dodajesz na cztery sposoby:

• + w lewym górnym rogu kanwy - albo Add step na środku pustej kanwy - otwiera wybór. Krok trafia za zaznaczony krok albo na koniec widocznego przepływu i łączy się z nim, gdy porty pasują. Krok startowy trafia zamiast tego przed obecny start i staje się nim.
• + przy wyjściu kroku otwiera wybór kroku, który idzie po tym wyjściu.
• Prawy przycisk na kanwie: ten sam wybór kroków otwiera się tam, gdzie kliknąłeś, i tam trafia krok. Pod nim Dodaj notatkę (Add a note) oraz, gdy coś skopiowano, Wklej (Paste).
• Przeciągnij krok z wyboru, żeby położyć go tam, gdzie go upuścisz, bez połączeń.

Aplikacje Google Workspace (Gmail, Google Calendar, Google Drive, Google Docs, Google Sheets) i Microsoft 365 (Outlook, Outlook Calendar, OneDrive, Excel) to osobne grupy w Apps and the web. Każda zawiera natywny trigger aplikacji, tam gdzie kanwa może go przyjąć, oraz po jednym wpisie na narzędzie każdego organizacyjnego połączenia MCP z odpowiednim serwerem - na przykład Create draft albo Send message. Narzędzia połączenia są przydzielane do tych grup według nazwy; narzędzie, którego żadna nie przejmuje, trafia do grupy samego serwera (Google Workspace, Microsoft 365), gdzie pokazywane są też Connect i nieprzetestowane połączenie. Narzędzi logowania (start_google_auth, login, verify-login) nie oferujemy.

Wybranie wpisu dodaje MCP call od razu ustawiony na to połączenie i to narzędzie, więc zapisane workflowy i kontrakt węzła się nie zmieniają. Wpis niczego nie ukrywa: ma plakietkę MCP i nazwę połączenia, pod nią stoi własna nazwa narzędzia w osobnym wierszu, a serwer jest nazwany raz w nagłówku grupy; nic nie jest ucinane.

Search steps znajduje go po którejkolwiek z nazw albo po aplikacji. Na kanwie krok czyta się Gmail · Create draft z plakietką MCP, a pod spodem widać połączenie i własną nazwę narzędzia; jego ustawienia mówią, że to wywołanie narzędzia MCP w tym połączeniu, i linkują do niego. Każde narzędzie Gmaila, które oferuje serwer, ma zwykłą nazwę, na przykład List labels lub Read thread; narzędzie spoza listy nazw pokazuje własną nazwę. Natywny trigger nie jest wywołaniem MCP i nie ma plakietki.

Bez pasującego połączenia grupa samego serwera pokazuje wiersz Connect do podłączenia serwera. Wypisane są tylko połączenia organizacji, a narzędzia połączenia to te, które zapisał jego ostatni test, więc przetestuj je ponownie, żeby zobaczyć nowe. Członek, który nie może edytować danego workflow, widzi same triggery. Członek, który go edytuje, ale nie zarządza serwerami MCP, widzi wszystkie akcje i nie dostaje wiersza Connect: serwer podłącza tylko osoba nim zarządzająca. Wiersze akcji aplikacji się wybiera, nie przeciąga: na kanwę można przeciągać tylko własne wiersze kroków.

Nowy krok nigdy nie ląduje na innym, zostaje zaznaczony, otwiera swoje ustawienia, gdy jakieś ma, a kanwa przewija się do niego, gdy wypada poza widok. W ciele pętli każdy nowy krok zostaje wpięty w ciało, więc tam zostaje. Wybór pokazuje to, co jest poprawne tam, gdzie jesteś: Loop item i Loop result tylko w ciele pętli, a pętlę, dopóki pętle nie są zagnieżdżone tak głęboko, jak pozwala publikacja.

Prawy przycisk na kroku daje Open settings, Duplicate, Switch off i Delete step. Gdy zaznaczonych jest kilka kroków, pasek na dole usuwa je razem.

Switch to view only w nagłówku pokazuje komuś, kto może edytować workflow, to, co widzi czytelnik: na kanwie nic się nie przesuwa, nie łączy ani nie usuwa, krok otwiera się tylko do odczytu po jednym kliknięciu, a Test draft i Publish znikają. Switch to editing przywraca edycję, a edytor zawsze otwiera się w trybie edycji. Zapis, który jeszcze trwa, w obu trybach i tak się kończy.

Katalog kroków rośnie z czasem

Wybór zasila lista węzłów zarejestrowanych we wdrożeniu, a nie stała lista. Rodzaj węzła zarejestrowany później pojawia się w nim od razu, bez zmiany workflow, który już zbudowałeś.

Notatki, porządkowanie i skróty

Dodaj notatkę (Add a note) pod wyborem kroków otwieranym prawym przyciskiem stawia notatkę obok kroków: markdown, pisany po dwukrotnym kliknięciu lub ołówkiem, przesuwany przeciąganiem i zmieniający rozmiar od rogów; gdy jest zaznaczona, jej przycisk palety rozwija próbki kolorów - szary, żółty, zielony, niebieski, fioletowy albo czerwony - żeby ostrzeżenie odróżniało się od zadania. Notatka jest zapisana w grafie, więc wersje, przywrócenia i kopie workflow ją zachowują, ale nic jej nie uruchamia ani nie sprawdza. Zaznaczone połączenie pokazuje +, które wstawia następny wybrany krok w jego środek, połączony z obu stron, gdzie porty pasują. Uporządkuj (Tidy up) na pasku narzędzi układa widoczne kroki od lewej do prawej jako jedną edycję do cofnięcia, przycisk mapy pokazuje minimapę, przycisk palety przełącza kroki między kolorem a trybem Prosty (patrz Jak rysowany jest krok), a przycisk klawiatury - albo ? - wypisuje wszystkie skróty; Tab otwiera wybór kroku. Żaden nie działa, gdy piszesz w polu.

Jak rysowany jest krok

Karta mówi, jakiego rodzaju jest krok, zanim powie, co robi. Nad nazwą mała etykieta zapisuje Rodzina · Rodzaj - AI · Classify, Dane · Save a record - a ikona leży na kafelku w barwie rodziny kroku, czyli tych samych sekcji, które ma wybór kroków:

Rodzina	Jej kafelek
Start	W kolorze tekstu - ciemny w jasnym motywie, jasny w ciemnym - i okrągły, na karcie z zaokrąglonym lewym końcem
AI	Pełny fiolet
Przepływ (Flow)	Szary
Dane (Data)	Morski (teal)
Aplikacje (Apps)	Biały z niebieskim obrysem, żeby znak marki leżał na nim bez zmian
Błąd (Error)	Czerwony

Rodziny różnią się jasnością i kształtem, nie tylko kolorem, więc rozróżni je też osoba z zaburzeniami widzenia barw i da się je poznać na kanwie oddalonej tak, że nic nie da się przeczytać. Minimapa też rysuje każdy krok w kolorze jego rodziny. Obramowanie i poświata karty nigdy nie należą do rodziny: należą do runu (patrz niżej), zmiany, zaznaczenia albo wyłączonego kroku.

Linia pod nazwą zaczyna się od tego, z czym krok pracuje - agent, model, tabela - i ciągnie się dalej tym, co krok ma robić, jak w gpt-4.1-mini · 3 categories.

Krok, który może wstrzymać run, ma na górze karty pasek, sformułowany na podstawie jego ustawień, nigdy runu:

Krok	Pasek mówi
Approval	Czeka na osobę
Wait	Czeka 2 dni (albo godziny, minuty, sekundy), Czeka do wskazanej chwili albo Czeka ustalony czas, gdy chwilę lub długość dostarcza wcześniejszy krok, albo Czeka na wywołanie - to wygrywa, gdy ustawiono i czas, i wywołanie
Run a workflow	Czeka na wywołany workflow; bez paska, gdy Wait for it to finish jest wyłączone
MCP call	Pyta przed zapisem albo Pyta przed każdym wywołaniem, według ustawienia zatwierdzania; bez paska, gdy nigdy nie pyta

Krok pytający człowieka ma pasek różowy; timer albo wywołanie - szary. Krok agenta paska nie ma: jego zatwierdzenia pochodzą ze spec samego agenta, a tego karta nie widzi.

Na kanwie runu krok czekający na osobę jest rysowany na różowo, z klepsydrą w plakietce, niezależnie od sposobu rysowania kroków.

Prosty rysuje wszystkie kafelki neutralnie, a minimapę na szaro, tak jak kanwa wyglądała, zanim kroki miały rodziny. Zachowuje to, co nie zależy od koloru: szarą etykietę, zaokrąglony koniec startu i neutralny pasek. Przełączysz go przyciskiem palety na pasku narzędzi kanwy albo w Ustawienia → Profil → Wygląd (Settings → Profile → Appearance) → Kroki workflow; jest zapamiętywany dla każdej przeglądarki, jak motyw.

Przeciągnij prawą krawędź, dolną krawędź lub prawy dolny róg zaznaczonego kroku, aby zmienić jego rozmiar. Karta ma od 200 do 560 px szerokości i do 400 px wysokości, i nigdy nie jest niższa, niż wymaga jej zawartość. Większa szerokość mieści więcej nazwy i podsumowania; większa wysokość pozwala zawinąć nazwę do trzech wierszy, a potem podsumowanie do dwóch, a porty zostają na dole karty.

Rozmiar jest zapisywany razem z wersją roboczą, więc cofanie, kopiowanie, wklejanie, duplikowanie, opublikowane wersje i eksport go zachowują. Przywróć rozmiar (Reset size) w menu kontekstowym kroku przywraca domyślny rozmiar, a Uporządkuj (Tidy up) rozmieszcza kroki wokół ich rozmiarów. Opublikowana wersja, run i porównanie pokazują zapisany rozmiar bez uchwytów.

Konfigurowanie węzła

Co robi każdy węzeł, czym się go konfiguruje i co znaczą jego błędy, opisuje referencja węzłów.

Kliknięcie zaznacza krok, a dwuklik otwiera go nad kanwą. W opublikowanej wersji lub w trybie View only wystarczy jedno kliknięcie. Nagłówek pokazuje nazwę kroku i jedno rozwijane podsumowanie brakującej konfiguracji. Rozwiń je, aby zobaczyć braki; wybranie pola przenosi do jego inputu. Po próbie testu lub publikacji szczegóły walidacji rozwijają się automatycznie.

Connect account w kroku lub wyborze aplikacji otwiera istniejącą konfigurację kont nad workflowem. Połącz konto organizacji, zakończ konfigurację i wybierz je w kroku. Selektor sekretu oferuje Add API key lub New secret, automatycznie wybiera zapisany sekret i przechowuje w drafcie tylko jego id. Trigger bez danych aplikacji OAuth oferuje Add credentials na miejscu; ten sam formularz sejfu zapisuje je dla organizacji.

Parameters to to, na czym krok pracuje i co ma zrobić, w jednej liście, z listą, na której krok pracuje, na początku: Items w Filter przed jego Condition. Settings to to, jak krok działa. Każda zmiana zapisuje się w drafcie od razu, więc Done tylko zamyka okno, a Delete step usuwa krok. Okno tylko do odczytu pokazuje każde ustawienie, wyłączone, z jego wartością.

Parametr przyjmujący tekst to jedno pole na wpisany tekst i wartości z wcześniejszych kroków naraz, na przykład New lead: {{Form.payload.name}} from {{Form.payload.company}}. Przycisk Data obok wstawia wartość w miejscu kursora, podobnie jak pole przeciągnięte z panelu Input. Wpisanie {{ wyświetla te same wartości, a wewnątrz payloadu triggera albo elementu pętli także pola, które widział tam ostatni przebieg testowy; dalsze pisanie zawęża listę, a Enter lub Tab wstawia placeholder.

Placeholder wskazuje krok i ścieżkę w jego wyjściu i jest w polu pokolorowany - na czerwono, gdy po wyjściu z pola okaże się, że nie wskazuje niczego, co ten krok może czytać. Jest sprawdzany przy publikacji jak każda wartość czytana z kroku i podąża za krokiem po zmianie jego nazwy. Z danymi przebiegu testowego wynik jest podglądany pod spodem. Nic nie jest wykonywane: gdy krok działa, każdy placeholder staje się tekstem swojej wartości, JSON-em dla listy albo obiektu, a taki, za którym nic nie stoi, kończy krok błędem INVALID_BINDING i go nazywa.

Każdy inny parametr - liczba, wybór, przełącznik, lista wpisana jako JSON - ma własną kontrolkę, a Data obok bierze wartość z wcześniejszego kroku zamiast niej. Data pokazuje tylko wartości osiągalne w tym miejscu i o zgodnym typie, pogrupowane według kroków, każdą z rodzajem wartości, a gdy takich nie ma, mówi No compatible upstream outputs. Parametr pokazuje wtedy, co czyta - Run an agent › text - a × wraca do wpisanej wartości.

Wymagany parametr bez wartości to problem walidacji, oznaczany na kroku, a nie wypełniany po cichu wartością domyślną. Niektóre parametry mają wartości strukturalne: listę wierszy, do której robisz Add row, zmieniasz kolejność i usuwasz, albo typowany wybór, który podmienia formularz pod spodem. Okno wchodzi w nie rekurencyjnie, zamiast odsyłać na osobny ekran.

Warunki

Filter a list, If i Switch decydują warunkiem zbudowanym z wierszy: pole elementu albo wartości, sprawdzenie - is equal to, is at least, contains, is not empty i pozostałe - oraz to, z czym jest porównywane. Liczba, true i false są porównywane jako takie, cała reszta jako tekst. Przy kilku wierszach Match all of these albo any mówi, jak się łączą, a pola, które pokazał ostatni przebieg albo dane testowe, są podpowiadane. Warunek jest zapisywany jako wyrażenie JMESPath, które krok wylicza. Write it as an expression edytuje go jako to wyrażenie, a takie, którego wiersze nie pokażą, zostaje wyrażeniem.

Zmiana nazwy reguły Switch, kategorii klasyfikatora, gałęzi błędu, gałęzi Split lub wyboru zatwierdzenia przenosi połączenia, powiązania i szybki log, które używały starej nazwy, chyba że zmieniono kolejność wpisów, wstawiono je lub usunięto, albo naraz zmieniły się dwie nazwy.

Nazywanie kroku, notatka i wyłączanie

Kliknięcie nazwy kroku u góry jego okna nadaje mu własną nazwę, widoczną na karcie i wszędzie tam, gdzie późniejszy krok wybiera, co czytać - dwa kroki Send a message stają się Tell sales i Tell support. Dwa kroki nie mogą mieć tej samej nazwy, bez względu na wielkość liter.

W Settings Note zostawia linijkę dla tego, kto będzie edytował workflow jako następny, oznaczoną na karcie, a zakładka ma kropkę, gdy cokolwiek tam zmieniono.

Wyłączenie tam Run this step albo Switch off w menu pod prawym przyciskiem zostawia krok na kanwie, przygaszony, i pomija go, gdy przebieg do niego dotrze: nic nie robi i przekazuje dalej to, co do niego dotarło. Publikacja odrzuca wyłączony trigger albo krok decydujący o drodze oraz krok czytający wyłączony krok, chyba że to, co do niego dociera - jedynym połączeniem wejściowym, od kroku włączonego - ma czytane pole, które wtedy przekazuje dalej. Wszystkie trzy są zapisywane w grafie, więc wersje je zachowują.

Dane kroku, dane testowe i testowanie jednego kroku

W trakcie edycji okno umieszcza parametry kroku między dwoma panelami. Input pokazuje, co przekazał jeden wcześniejszy krok, najpierw ten najbliższy; gdy jest ich więcej, w nagłówku panelu można wybrać dowolny krok, z którego ten może czytać. Output pokazuje, co przekazał sam krok, oba z ostatniego przebiegu testowego uruchomionego w edytorze albo z najnowszego przy otwarciu. Table układa dane w wiersze, listę rekordów po jednym wierszu na rekord. JSON pokazuje je takimi, jakie są, a Fields wymienia każde pole po ścieżce ze zwykłym słowem na to, co zawiera - text, number, list, ID: ścieżki, które czyta późniejszy krok.

Przed pierwszym przebiegiem oba panele pokazują w ten sam sposób pola, które krok przekazuje, i je także można przeciągać; krok, do którego nic nie prowadzi, mówi Not connected yet. Tabela pokazuje pierwsze 50 wierszy, dopóki Show more nie rozłoży reszty, a komórka przycięta do szerokości kolumny pokazuje całą wartość po najechaniu.

Kolumnę albo pole z panelu Input można przeciągnąć na parametr, który wtedy czyta je z tamtego kroku, tak jakby wybrano je przez Data - do tekstu jako placeholder. Pole, które nie pasuje, zostaje odrzucone z powodem: typ, którego parametr nie przyjmuje, albo krok, który nie zawsze działa przed tym.

Wewnątrz wartości bez określonego kształtu, takiej jak values mapowania albo payload triggera, typ jest taki, jaki pokazał przebieg. Przycisk Data oferuje wartości bez kształtu każdemu parametrowi, z Field inside it na ścieżkę. Przytrzymanie przeciąganego pola przy górnej lub dolnej krawędzi formularza go przewija, więc da się sięgnąć parametru poza widokiem.

Keep as test data zostawia wyjście na kroku, a Set test data pozwala wpisać je jako obiekt JSON o rozmiarze najwyżej 64 000 bajtów. Przebieg testowy przekazuje dane testowe dalej zamiast uruchamiać krok, więc wolne wywołanie modelu albo zapis do żywego systemu robi się raz i używa ponownie. Krok decydujący o drodze nigdy nie trzyma danych testowych, a publikacja usuwa je wszystkie: opublikowana wersja zawsze uruchamia swoje kroki. Ikona pinezki oznacza kartę, a Remove test data je usuwa.

Test step uruchamia sam krok i jest głównym przyciskiem panelu, dopóki nie ma danych. Przebieg zachowuje tylko ten krok i kroki do niego prowadzące, a każdy z nich o znanym wyjściu, z danych testowych albo z ostatniego przebiegu testowego, przekazuje je zamiast działać. Reszta działa, a nic po tym kroku już nie. Krok, który zapisuje, najpierw pyta, bo test naprawdę zapisuje. Kroku w pętli nie da się przetestować osobno, bo działa raz na element, więc testuj pętlę. W trakcie testu kwadrat obok Test step go zatrzymuje. Gdy test skończy się bez uruchomienia kroku - bo go zatrzymano, run poszedł inną gałęzią albo skończył się wcześniej - znak ostrzeżenia w tym miejscu mówi, co się stało. Przez API to samo robi step w POST /api/v1/workflow-runs.

Wybór zasobów

Ustawienie, które przypina zasób, otwiera pole wyboru zamiast pola tekstowego, więc krok nazywa realną rzecz, którą ma Twoja organizacja:

Pole wyboru	Co przypina
Agent i Version	Agenta, po jego awatarze i opisie, a potem jedną z jego opublikowanych wersji, z oznaczoną wersją live oraz datą i notatką każdej. Zmiana agenta czyści przypiętą wersję, bo wersja należy do jednego agenta. Karta kroku pokazuje wtedy awatar agenta i „nazwa · v3”
Table i Columns	Virtual Table, a potem kolumny, które krok odczytuje — ograniczone do bieżącego schematu tej tabeli
Secret	Sekret w vault, przez referencję. Krok zapisuje id sekretu, nigdy jego wartość
MCP server i Tool	Jeden z serwerów MCP organizacji, ze znakiem jego usługi, a potem jedno z narzędzi, które wypisał przy ostatnim teście. Wybór wymaga prawa do edycji workflow - z roli lub z udzielonego dostępu, tak jak publikacja kroku - a nie mcp:manage; tylko osoba zarządzająca serwerami może przetestować serwer lub dodać kolejny

Każde pole wyboru rozróżnia jednakowo nazwane wiersze przez kontekst i oznacza referencję, której cel zniknął. Pola wyboru Agent i Secret mają też link do utworzenia nowego — zawsze, nie tylko gdy lista jest pusta — natomiast pole wyboru Table nie ma żadnego. Tabela, której schemat zmienił się od czasu powiązania, mówi o tym i oferuje Rebind to the current schema, więc nieaktualny zestaw kolumn jest widoczną zachętą, a nie cichym pęknięciem.

Ewaluacje kroku z modelem

Krok, na który odpowiada model - agent, Ask a model, Classify, Extract data, Summarize or translate albo decyzja - ma zakładkę Evals: przypadki, które powinien obsłużyć, i co powinna wtedy mówić jego odpowiedź. Add a case bierze wejście, z którym krok był ostatnio testowany - wejście runu i to, co przekazały kroki przed nim - więc najpierw przetestuj krok raz, a potem nazwij przypadek i wskaż, gdzie w odpowiedzi patrzeć (text, category, ścieżka taka jak structured.amount albo nic dla całego wyjścia), i czy ma zawierać, nie zawierać czy równać się wartości, bez względu na wielkość liter i spacje wokół.

Try uruchamia run testowy kroku dla każdego przypadku, sprawdzany i rozliczany jak każdy inny, a każdy przypadek jest oznaczany jako zaliczony lub nie, gdy jego run się skończy, z tym, co powiedziała odpowiedź, albo powodem, dla którego jej nie było. Przypadek, którego run nie może wystartować - za dużo pracy w toku, wyczerpany budżet miesięczny - jest oznaczany jako niezaliczony z powodem. Uruchamiaj przypadki po zmianie promptu, modelu lub instrukcji. Krok mieści do 50 przypadków, a ich uruchomienie wymaga workflows:edit, jak testowanie szkicu.

Agenci z katalogu

Run an agent wybiera opublikowanego agenta z katalogu i przypina jego aktualną opublikowaną wersję. Możesz wybrać starszą wersję; opublikowany workflow zachowuje niezmienne przypięcie. W istniejącym niekompletnym kroku Użyj opublikowanej wersji uzupełnia brak przed testem. Agentów tworzysz i edytujesz w Agent Builderze.

Starsze grafy z agentem skonfigurowanym wewnątrz kroku nadal działają. Edytor zachowuje tę konfigurację, dopóki świadomie nie zastąpisz jej agentem z katalogu. Nowych agentów nie buduje się w workflows. Max cost (USD) nadal ogranicza wykonanie obok pozostałych budżetów.

Gdy krok jest wolny albo zawodzi

W Settings kroku sekcja When it is slow or fails ustala jego politykę. Handle errors daje krokowi port Error: błąd, którego ponowienia nie rozwiązały, wychodzi nim do kroku Handle error albo czegokolwiek innego, co podłączysz, zamiast kończyć run błędem. Tries to łączna liczba prób kroku, a Wait between tries i First wait ustalają przerwę między próbami. Krok, którego wywołania nie da się bezpiecznie powtórzyć, na przykład uruchomienie agenta, mówi o tym i nigdy nie jest ponawiany. Time limit przerywa wywołanie po tylu sekundach. Co każde ustawienie robi w trakcie runa, opisuje referencja węzłów.

Binding do wartości bez zadeklarowanego kształtu - bieżącego elementu pętli, payloadu triggera - oferuje pod źródłem pole Field inside it, w którym wpisujesz ścieżkę wewnątrz tej wartości, na przykład record_id albo fields.Email. Run sprawdza tę ścieżkę, gdy krok zostaje wysłany do wykonania, bo tylko run wie, co zawiera wartość.

Szybki log

Szybki log zapisuje jedną linię w logu workflow za każdym razem, gdy krok kończy się w przebiegu, dzięki czemu widzisz, co zrobił workflow, bez otwierania każdego przebiegu. To ustawienie kroku. Najedź na kartę i wybierz + Log: pasek LOG zadokuje się przy prawej stronie karty na zewnątrz, uchwyty wyjść kroku przesuną się na jego zewnętrzną krawędź, a każde logowane wyjście ma swój pasek. Usuń szybki log, aby przestać logować ten krok.

Wiadomość to szablon o długości od 1 do 500 znaków, domyślnie {{step}} → {{outcome}}. Może używać {{step}}, czyli nazwy kroku, oraz {{outcome}}, czyli wyjścia, którym krok wyszedł. Może też używać pól wyjścia kroku przez ich ścieżkę, na przykład {{record.id}}, oraz {{error.code}} i {{error.message}} dla błędu. Odwołanie, które nie daje się rozwiązać, jest puste, tak samo jak indeks listy: ścieżki przechodzą tylko przez obiekty.

Outputs wybiera, które wyniki zapisują linię. Domyślnie każde wyjście; zaznacz mniej, aby logować tylko je, a usuń szybki log, aby nie logować nic. Szybki log nie jest dozwolony na kroku Loop item ani Loop yield. Dodaj go do samego kroku For each: zapisuje linię przez wyjście done, gdy jego pętla się zamyka. Krok bez wyjść loguje swoje błędy.

Błędy są zapisywane zawsze. Błąd, którego nie kieruje żaden port error, jest logowany niezależnie od zaznaczonych wyjść, bo log służy właśnie temu, by cichy błąd przebiegu nie przeszedł niezauważony. Błąd skierowany portem error podlega filtrowi Outputs jak każdy inny wynik.

Wiersz nie jest zapisywany dla kroku pominiętego, wyłączonego lub nigdy nierozpoczętego, ani dla takiego, który ponowienie od nieudanego kroku ponownie wykorzystało zamiast uruchomić. Log nigdy nie zmienia przebiegu: wiadomość, której nie da się zapisać, jest pomijana, a przebieg toczy się dalej tak, jak by się toczył. Przebieg testowy też zapisuje wiersze, oznaczone jako testowe, a wiersz z kroku, który przekazał przypięte dane testowe, jest oznaczony jako przypięty.

Wiersze są przechowywane razem z przebiegiem i usuwane razem z nim, gdy retencja historii usuwa przebieg (zob. Ustawienia workflow). Czytasz je na stronie Logs albo, osobno dla każdego kroku, w widoku przebiegu.

Połączenia i scope foreach

Krawędź rysujesz, łącząc port wyjściowy jednego węzła z portem wejściowym innego węzła. Edytor odrzuca połączenie między portami, które niosą różne kształty, zanim je narysuje, więc niezgodne połączenie nigdy nie ląduje na kanwie, a narysowanie połączenia, które już istnieje, nic nie robi.

Krawędź ustala kolejność, w jakiej wykonują się kroki; nie przenosi żadnych danych. Wartości, które krok czyta, to jego bindingi, opisane w sekcji Konfigurowanie węzła.

Żebyś nie musiał wiązać każdego pola ręcznie, połączenie dwóch portów, które niosą dokładnie ten sam kształt — na przykład wyjścia Echo z wejściem Relay — wiąże też każdy input celu z polem o tej samej nazwie na źródle. Pole, które już związałeś, zostaje nietknięte.

Gdy kształty się różnią albo port nie niesie danych, jeden wybór i tak zapada za Ciebie: krok pracujący na jednej liście, podłączony za krokiem, który przekazuje dokładnie jedną - Filter a list za List records - czyta tę listę. Nic więcej nie jest wiązane i każde źródło wybierasz sam przez Data. Undo (Ctrl/Cmd + Z) cofa połączenie razem z jego bindingami, a późniejsze usunięcie krawędzi zostawia jej bindingi na miejscu, więc usuń je lub zwiąż ponownie w ustawieniach kroku.

Aby usunąć połączenie, zaznacz je: kliknij linię, a zostanie narysowana grubiej i pojawi się na niej przycisk Delete connection. Naciśnij przycisk albo Delete lub Backspace, a połączenie zniknie, podczas gdy oba kroki zostaną. Połączeń opublikowanej wersji nie można zaznaczyć, więc nie można ich usunąć.

Krok For each wykonuje swoje ciało raz na każdy element listy. Ciało nie jest osobnym dokumentem - jest częścią tego samego płaskiego grafu, pokazaną osobno. Edit loop body na kroku, które podaje, ile kroków zawiera ciało, wchodzi do tego widoku, a okruszki Workflow scope w rogu kanwy pokazują, gdzie jesteś, od Workflow w dół do pętli, którą otworzyłeś. Każdy okruszek nawiguje z powrotem na zewnątrz.

Ciało zaczyna się od Loop item, z którym łączy się port Each item pętli, i kończy na Loop result; nic w nim nie łączy się z powrotem z pętlą, która idzie dalej przez Done, gdy każdy element przeszedł przez ciało. Wybór kroków i źródła binding podążają za scope, w którym jesteś, a krok w ciele może czytać wszystko, co działało przed pętlą. Co robi pętla, opisuje referencja węzłów.

Równoległe gałęzie

Każdy krok może wysłać jeden port wyjściowy do kilku kroków, a te działają w tym samym czasie. Krok Split robi to samo z nazwanymi gałęziami i obiera je wszystkie; nie ma warunku i nie może kierować błędów. Która gałąź skończy pierwsza, nie jest określone, więc nic nie może polegać na kolejności. Narysuj odnogi i połącz je tam, gdzie późniejszy krok potrzebuje tego, co zrobiły.

Krok z kilkoma połączeniami wejściowymi jest złączeniem (join) i nie potrzebuje Merge. Uruchamia się, gdy każdy krok prowadzący do niego się zakończy, o ile choć jedno z jego połączeń jest aktywne: odnoga, której If nie obrał, go nie wstrzymuje. Jest pomijany, gdy żadne połączenie nie jest aktywne oraz gdy krok prowadzący do niego zawiódł bez ścieżki błędu. Jego bindingi mogą czytać tylko kroki, które na pewno wykonały się wcześniej, więc złączenie może czytać każdą odnogę grupy równoległej, ale nie gałąź If, która mogła się nie wykonać.

Merge ma ustawienie Wait for. The branch that ran przekazuje dalej wyjście jedynej gałęzi, która do niego dotarła, a publikacja go odrzuca, gdy dwa jego wejścia mogą działać razem. All branches czeka na każde wejście i przekazuje każde z nich według nazwy jako branches, więc kolejne kroki czytają branches.<nazwa>; każde połączenie ma Branch name. Publikacja odrzuca je, gdy wejście może się nie wykonać - ze wskazaniem go - albo gdy może działać tylko jedno. Podłączenie drugiej odnogi do merge'a wybiera ustawienie, którego potrzebuje graf, a zmiana nazwy gałęzi przenosi kroki, które ją czytają, w jednym cofnięciu. Szczegóły są w opisie węzłów.

Publikacja odrzuca też graf z dwoma krokami Output albo dwoma krokami Respond to webhook, które mogą oba działać w jednym runie, oraz Error handler zasilany przez dwa kroki, które mogą zawieść w tym samym runie. Daj każdej odnodze własny.

Gałąź, która zawodzi bez ścieżki błędu, kończy run błędem. Kroki obok niej nie zaczynają niczego więcej, a to, co miały w toku, jest zamykane: oczekujące zatwierdzenia, timery i runy agentów, na których krok jest zaparkowany. Krok, który skończy się potem, jest zapisany jako Finished after the run stopped, z zachowaną pracą, a ponowienie używa go zamiast robić to jeszcze raz. Status runa wynika z jego aktywnych kroków, więc gałąź czekająca na zatwierdzenie jest widoczna, nawet gdy inna jeszcze działa.

Budżet runa jest wspólny. Każdy krok, który wydaje, i każdy workflow, który wywołuje, czerpie z tego, co limit zostawia po wydatkach i po tym, co trzymają inne kroki w toku, nigdy więcej niż własne max_cost_usd. Krok, który zastaje resztę w rękach swoich sąsiadów, czeka i pyta ponownie, za każdym razem nieco później, zamiast dostać całą resztę. Rezerwacja kończy się, gdy krok, który ją wziął, się zakończy.

Rodzeństwo kroków AI działa równolegle pod budżetem runa tylko wtedy, gdy każdy ma własne max_cost_usd: krok bez niego trzyma całą resztę, więc sąsiedzi czekają, aż się zakończy.

O tym, ile gałęzi działa naraz, decyduje worker, nie run. Nie ma limitu na run, więc gałęzie jednego runa mogą zająć każdy slot workflow workera, WORKER_WORKFLOW_CONCURRENCY (domyślnie pięć, zobacz Konfiguracja), a reszta czeka w kolejce. Run, na który ktoś czeka, wyprzedza ten, który wystartował sam. Szerokie rozgałęzienie w jednym runie spowalnia więc inne runy na tym workerze; niech będzie tak szerokie, jak wymaga praca.

Informacja zwrotna walidacji

Edytor sprawdza graf podczas edycji. Przed testowaniem niekompletne kroki mają neutralny znacznik konfiguracji, a kanwa pokazuje Finish setup. Rozwiń znacznik, aby zobaczyć listę i przejść do kroku. Testowanie lub publikacja ujawnia błędy, a opuszczenie pustego wymaganego pola pokazuje komunikat przy nim. Publikacja pozostaje zablokowana do usunięcia wszystkich problemów walidacji.

Ustawienia kroku pozostają krótkie. To, czego krok potrzebuje, i to, co już ustawiłeś, widać od razu; opcjonalne ustawienia wciąż z wartościami domyślnymi czekają za przyciskiem, który je liczy - 3 more options - i wysuwa je nad sobą, dopóki nie wybierzesz Fewer options, a to, jak krok działa, czeka w zakładce Settings. Wymagana wartość, której jeszcze nie podano, nie jest oznaczana przy polu, dopóki nie opuścisz tego pola albo nie spróbujesz uruchomić lub opublikować: znacznik kroku na kanwie mówi o niej od początku. Opis, który tylko powtarza nazwę pola, jest podpowiedzią przy nazwie zamiast wiersza pod polem.

Komunikaty nazywają konkretną usterkę: wymagany input bez wartości, input ustawiany przez więcej niż jedno źródło, połączenie, którego porty niosą różne kształty, krok, którego nie da się osiągnąć od startu, pętlę z powrotem do wcześniejszego kroku, wartość, która czyta krok niewykonany na każdej prowadzącej tutaj ścieżce, albo połączenie, które przekracza granicę ciała pętli — do środka lub na zewnątrz.

Kontrola edytora to podgląd; publikowanie jest autorytetem

Walidacja w edytorze to szybkie lustro reguł, które wymusza serwer. Istnieje po to, by złapać problem, gdy na niego patrzysz, ale nigdy nie jest ostatnim słowem: publikowanie ponownie uruchamia pełną walidację na serwerze, a problem, który edytor przeoczył, jest pokazywany tak samo, przy węźle lub polu, do którego należy.

Autozapis i banner konfliktu rewizji

Twój draft zapisuje się sam. Krótka przerwa po tym, jak przestajesz edytować, zapisuje bieżący graf, a status pod tytułem, za tagami, to odzwierciedla — Unsaved changes, gdy zapis oczekuje, Saving…, gdy trwa, Saved, gdy się dokona, i Save failed — will retry, gdy się nie dokonał.

Każdy zapis jest zapisywany względem rewizji, którą otworzyłeś, więc draft edytowany w dwóch miejscach naraz nie może po cichu nadpisać. Gdy to się zdarza, edytor podnosi banner zatytułowany This draft changed elsewhere: Someone edited this workflow since you opened it. Overwrite keeps your changes; reload replaces them with the latest saved draft. Wybierasz:

• Overwrite — zachowaj swoją wersję i zapisz ją nad tą zapisaną gdzie indziej.
• Reload — odrzuć niezapisane zmiany i weź ostatnio zapisany draft.

Publikowanie wersji i historia wersji

Konfiguracja uprawnień automatyzacji wymaga sesji członka: publikowanie triggera webhook, harmonogramu, tabeli, formularza, GitHub, e-mail lub kanału, włączanie jego ekspozycji, rotacja sekretu lub linku formularza, zmiana harmonogramu i wybór workflow obsługi błędów. Klucze API organizacji mogą publikować ręczne workflow, rozpoczynać dozwolone przebiegi i wstrzymywać automatyzację; nie mogą zachować uprawnień użytkownika wystawiającego klucz na przyszłe zdarzenia. W instalacji przedpremierowej istniejącą automatyzację opublikuj ponownie z zaufanej sesji członka; historyczne wiersze nie zapisują pochodzenia klucza publikującego.

Kroki MCP sprawdzają aktualną widoczność połączenia, dostęp grup i granty do zasobu oraz allowed_tools przy publikacji i wykonaniu. Pusta lista nie pozwala na żadne narzędzia. Odebranie dostępu po publikacji blokuje wykonanie przed odczytem sekretów i kontaktem z serwerem.

Ekstrakcja DOCX czyta XML strumieniowo i zatrzymuje się na skonfigurowanym limicie znaków, z ograniczeniem rozpakowania i zagnieżdżenia. Egzekwowanie limitu nie wymaga zbudowania całego drzewa dokumentu.

Historia ładuje po 50 wpisów metadanych; More pobiera starsze wersje. API przyjmuje before i limit (1–100), zwracając next_before, dopóki istnieją starsze wersje. Graf jest pobierany dopiero przy otwarciu wersji. Błąd strony można ponowić bez utraty już wczytanych wpisów.

Publish zamraża bieżący draft jako niezmienną wersję, która działa — wersja nigdy nie jest zmieniana po utworzeniu. Okno publikowania mówi, którą wersję utworzy, i przyjmuje opcjonalną Release note opisującą, co się zmieniło; gdy draft nie zmienił się od aktywnej wersji, mówi to najpierw. Jeśli graf wciąż ma problemy, publikowanie jest zablokowane z Fix the problems below before publishing, więc wersja, która by nie przeszła walidacji, nigdy nie powstaje.

Publikowanie nie kończy Twojej edycji. Draft istnieje dalej niezależnie od każdej opublikowanej wersji, więc edytujesz go od razu dalej. Versions pod More w nagłówku edytora otwiera każdą opublikowaną wersję wraz z jej release note, a aktywną oznacza Live. View otwiera wcześniejszą wersję tylko do odczytu - opublikowana wersja jest tylko do odczytu, a aby wprowadzić zmiany, edytujesz draft dalej.

Aby wrócić do opublikowanej wersji, otwórz ją przez View i wybierz Restore to draft. Po potwierdzeniu draft przejmuje graf tej wersji, a wszystko, co w drafcie było nieopublikowane, przepada. Sama wersja się nie zmienia i nic nie zostanie opublikowane, dopóki znowu nie opublikujesz draftu. Undo zaczyna od nowa od przywróconego grafu. Jeśli ktoś zmienił draft od chwili, gdy go otworzyłeś, przywrócenie zostaje odrzucone z tym samym bannerem konfliktu, który zgłasza zapis, zamiast nadpisać jego zmianę. Przywrócenie wymaga workflows:edit na tym workflow, a zarchiwizowanego workflow nie da się przywrócić. Każde przywrócenie trafia do dziennika audytu jako workflow.version_restored.

Compare with draft w podglądzie wersji rysuje wersję i szkic na jednym płótnie: każdy krok, który szkic dodał, zmienił albo usunął, jest oznaczony na swojej karcie, a lista obok wymienia każdy zmieniony krok z tym, co się w nim zmieniło - ustawienie, wejście, nazwę, notatkę lub wersję, czy jest wyłączony i co robi, gdy działa wolno albo zawodzi. Przesunięcie kroku i przypięte dane testowe nie są zmianami. Show this version wraca do samej wersji.

Ustawienia workflow

Settings grupuje czas i obsługę błędów, historię i retencję oraz limity w rozwijanych sekcjach. Sekcje ze zmienionymi wartościami są początkowo otwarte. Strona uruchomień zaczyna się od historii; Live performance rozwija statystyki opublikowanych uruchomień. Runs i Logs trzymają dodatkowe kontrolki pod Filters. Odrzucony filtr uruchomienia z linku automatycznie odsłania swoje pole i błąd.

Wyniki inline mają wspólne limity: WORKFLOW_RUN_MAX_INLINE_RESULT_BYTES (64 MiB na run) i WORKFLOW_ORG_MAX_INLINE_RESULT_BYTES (1 GiB łącznie dla zachowanych runów). Rezerwacje obejmują kompaktowe wyniki prób, również syntetyczne wyjścia pętli, oraz możliwe kopie w wyniku runa, odpowiedzi webhooka i błędzie. Nie mierzą fizycznego storage PostgreSQL ani nie zastępują polityki całego deploymentu. Małe końcowe rekordy błędu mogą przekroczyć pełny limit, aby zamknąć przebieg. WORKFLOW_INLINE_RESULT_LIMIT nie da się ominąć routingiem błędów; koszty pozostają, efekty nie są automatycznie ponawiane. Handler mógł już wykonać działanie przed odmową zapisu wyniku. Użyj referencji do plików albo retencji historii, która zwalnia rezerwacje.

Wznowiony agent zachowuje ciaśniejszy limit: zapisany na pauzie albo sumę dotychczasowego kosztu i aktualnie pozostałego budżetu workflow. Wydatki równoległych gałęzi podczas oczekiwania na approval nie przywracają dawnego zapasu. Każdy przypadek eval zużywa jednostkę limitu runów, również wewnątrz paczki; wyczerpane przypadki są zapisane jako refused. Pierwsza rezerwacja żądania HTTP jest zaliczana pierwszemu przypadkowi.

Przypięte wyniki importują zagnieżdżone referencje plików po sprawdzeniu aktualnego dostępu. Admission i retencja współdzielą blokadę cyklu życia pliku: zatwierdzony import chroni producenta, a retencja ponawia sprawdzenie po oczekiwaniu na blokadę. Przykłady edytora zachowują dane najnowszego runa mimo opóźnionych starszych odpowiedzi; wklejanie zachowuje notatki, a mieszane zmiany notatek i stepów są stosowane razem.

Migracja 0231_workflow_result_bytes.py odtwarza liczniki z istniejącego nieskompresowanego tekstu JSON, konserwatywnie względem nowych kompaktowych rezerwacji. Na czas backfill zatrzymaj zapisujące API i workery. Historie przekraczające kwotę pozostają zachowane, ale blokują kolejne duże wyniki do sprzątnięcia lub zwiększenia limitu. Nie odtwarza to wcześniej usuniętych treści.

Rezerwacje obejmują także początkowe wejście runa, snapshot draftu w trybie testowym i każdy zapisany payload wznowienia Wait. Admission i resume rezerwują bajty przed zapisem lub wybudzeniem kroków; odmowa zwraca WORKFLOW_INLINE_STORAGE_LIMIT (429). Link resume uwierzytelnia przed odczytem body. Migracja 0232_workflow_input_bytes.py dodaje istniejące payloady do liczników, zachowując wyniki i opłaty. Na czas backfillu zatrzymaj zapisujące API i workery; organizacja już przekraczająca limit musi usunąć zachowaną historię albo zwiększyć limit przed kolejnymi zapisami.

Drafty, opublikowane wersje i zachowane importy chronią wskazane pliki przed retencją. Usunięcie workflow-producenta jest odrzucane, dopóki inne workflow wskazuje jego pliki; usuń odwołania albo zarchiwizuj workflow. Edycja, admission, importy i cleanup współdzielą blokadę cyklu życia organizacji. Usunięcie sprawdza zależności runów przed usunięciem triggerów i próbuje wyrejestrować hook GitHub przez istniejącą integrację konta; błędy dostawcy pozostają w logach.

Combine by key przyjmuje skalarne klucze i odrzuca listy lub obiekty bez retry. Tworzenie eval cases serializuje kontrolę limitu i nadawanie pozycji. Dashboard sumuje wszystkie widoczne workflow, również powyżej 500, a zakończenie runa odświeża listę plików niezależnie od czasu odczytu kroków.

Zagnieżdżone importy są deduplikowane po ID pliku i ograniczone przez WORKFLOW_GRAPH_MAX_BINDINGS przed walidacją w bazie.

Run źródłowy zostaje, gdy trwa jego retry albo inny zachowany run importuje któryś z jego plików. Zakończenie retry nie unieważnia plików nadal wskazywanych przez jego kroki.

Settings w menu More w nagłówku edytora zawierają to, z czym workflow jest uruchamiany, a nie to, co robi. Należą do workflow, nie do wersji: zmiana dotyczy każdego przebiegu rozpoczętego po niej, a publikacja je zachowuje.

• Timezone - w niej czytane jest wyrażenie cron harmonogramu, także przy zmianie czasu, i w niej pisze krok Date & time, który nie wskazuje własnej strefy. Przebieg zachowuje tę ustawioną w chwili startu. Bez ustawienia UTC. Pole mówi, która jest tam teraz godzina, i odrzuca strefę, której przeglądarka nie zna.
• Default deadline - termin, który dostaje przebieg, gdy to, co go uruchamia, nie podaje żadnego.
• Error workflow - opublikowany workflow zaczynający się od On failure of a workflow, uruchamiany raz, gdy przebieg zawiedzie. Zobacz Gdy inny workflow zawiedzie.
• Keep runs for i Keep runs that succeeded - codzienne sprzątanie usuwa przebieg i zapisane przez niego pliki po tylu dniach od jego końca, a udany przebieg następnego dnia, gdy udanych się nie przechowuje. Bez ustawienia przebiegi zostają na zawsze.

Limits ograniczają, co jego runy robią naraz i ile wydają, ponad własnymi limitami każdego kroku - w tym pułapem kosztu kroku agenta:

• Runs under way at once - prawdziwy run uruchomiony ponad limit jest odrzucany z 429, dopóki któryś się nie skończy. Nadawca webhooka lub GitHub dostaje prośbę o ponowienie, harmonogram czeka na kolejny takt, a zdarzenie tabeli lub odpowiedź z formularza ponad limit są odrzucane. Skrzynka jest czytana ponownie minutę później, niezależnie od odstępu, więc wiadomość czeka na koniec runu - chyba że limit zajmują runy czekające na zatwierdzenie: wiadomość jest wtedy pomijana dla tego workflow, a dziennik audytu to zapisuje (workflow.mail_message_skipped). Runy testowe nie są ani liczone, ani wstrzymywane.
• Most one run may spend - własny budżet runu, ciaśniejszy z niego i budżetu wersji: run, który go osiągnie, zatrzymuje się przed kolejnym krokiem, poza budżetem.
• Most its runs may spend a month - liczony w miesiącu kalendarzowym w UTC, łącznie z runami testowymi. Po osiągnięciu żaden run nie startuje - 402 - dopóki nie zmieni się miesiąc albo budżet nie zostanie podniesiony. Strona runów pokazuje wydatki miesiąca na tle budżetu.

Przez API zastępuje je PUT /api/v1/workflows/{id}/settings.

Retencja usuwa treść i pliki przebiegów, lecz zachowuje kwoty oraz czas przyjęcia przebiegu na potrzeby miesięcznego rozliczenia budżetu. Usunięcie historii nie odnawia miesięcznego budżetu workflow. Kosztów usuniętych przed wprowadzeniem tego rozliczenia nie można odtworzyć.

Uruchamianie workflow

Test draft w nagłówku edytora od razu uruchamia szkic, nigdy opublikowaną wersję - Ctrl/Cmd + Enter też - najpierw prosząc o pola, które deklaruje wyzwalacz Manual albo API. Run pokazuje się potem na kanwie na bieżąco. Plakietka w rogu każdego kroku mówi, na jakim jest etapie - Pending, Starting, Running z bieżącym czasem, Waiting, Failed, Needs attention, Skipped albo Not reached - a krok, który się udał, pokazuje, ile trwał. Połączenie prowadzące do działającego kroku jest animowane, przebyta ścieżka zmienia kolor na zielony, a gałąź, którą run nie poszedł, blednie. Krok, który zawiódł, pokazuje błąd pod swoją kartą i raz się trzęsie.

Połączenie mówi, ile elementów nim przeszło, gdy krok przed nim przekazał listę, a pasek na dole mówi, jak run stoi, z Open run do jego strony. Dopóki run trwa, kwadrat obok Test draft go zatrzymuje, bez pytania. Kanwa zachowuje run po jego końcu; następna edycja go ukrywa i zostawia pasek z informacją, że graf się od tego czasu zmienił, nadal z Open run. Krok, który poczekał i poszedł dalej, liczy jedną próbę, nie dwie. Test draft czeka, dopóki zmiana się zapisuje, i mówi, czemu nie może ruszyć, gdy szkic ma problemy.

Runs w nagłówku edytora i ikona runów na karcie workflow otwierają jego runy, od najnowszego, każdy z jego statusem, tym, czy uruchomił draft czy opublikowaną wersję, co go uruchomiło, kiedy, jak długo trwał i ile kosztował. Start a run uruchamia run ręcznie: Test the draft uruchamia draft w obecnym stanie, a Published version uruchamia żywą wersję. Jego Input (JSON) to to, co krok Input workflow przekazuje dalej jako payload.

Nad listą How it ran podsumowuje prawdziwe runy z ostatnich 7, 30 lub 90 dni: ile się uruchomiło i ile zawiodło, jaki odsetek zakończonych się udał, typowy czas i czas, w jakim kończy się 95 na 100, oraz ile kosztowały w poszczególne dni. Karta kosztu podaje też wydatki z tego miesiąca, łącznie z runami testowymi, na tle miesięcznego budżetu workflow - na czerwono, gdy jest wyczerpany. By step pokazuje, skąd wziął się czas, koszt i błędy, od najdroższych. Przez API to GET /api/v1/workflows/{id}/stats?days=30.

Jeśli workflow w tym okresie prosił osobę o zatwierdzenie, sekcja Zatwierdzenia (Approvals) podsumowuje, jak ludzie zdecydowali: Zatwierdzone bez zmian (Approved as proposed), Zmienione przed zatwierdzeniem (Edited before approval) z medianą tego, jaką część tekstu zmieniły poprawki, Odrzucone (Rejected), ile próśb wygasło, oraz Czas do decyzji (Time to decide), typowy i taki, w jakim zapada 95 na 100. Tabela podaje te same liczby dla każdego kroku zatwierdzenia.

Okno to te same dni, liczone od chwili, gdy osobę o coś zapytano, a runy testowe są pominięte. Odsetek zatwierdzonych i odsetek zatwierdzonych bez zmian (w API acceptance_rate i unchanged_rate; karta pokazuje drugi) liczy się z próśb, o których zdecydowano, czyli zatwierdzonych lub odrzuconych: prośba, która wygasła albo została anulowana wraz z runem, nie doczekała się decyzji, więc jest policzona, ale nie wchodzi do odsetków. Krok, którego nie można edytować, liczy się jako zatwierdzony bez zmian. Liczby podają, co się stało, i niczego nie oceniają.

Liczby są per krok i per dzień, nie per rodzaj wiadomości. Aby porównać kategorie, skieruj każdą do własnego kroku zatwierdzenia.

To, jak bardzo poprawka coś zmieniła, mierzy się raz, w chwili decyzji, tym samym narzędziem co text.compare, znak po znaku: 0, gdy osoba zatwierdziła propozycję bez zmian w kroku, który można edytować, aż do 1, gdy nic z niej nie zostało. Krok, którego nie można edytować, odrzucenie i wygaśnięcie nie mają takiej liczby. Poprawka rozstrzygnięta, zanim zatwierdzenia zaczęto mierzyć, też jej nie ma i nie wchodzi do mediany, zamiast liczyć się jako brak zmian; gdy w okresie nie zmierzono żadnej poprawki, karta pokazuje Change not measured („Nie zmierzono zmiany”).

Te same liczby przychodzą przez API w bloku approvals statystyk. Dla wszystkich workflow, które widzisz, w wybranych datach, GET /api/v1/workflow-approvals/stats?from=2026-10-01&to=2026-10-31 podaje sumy i pięć workflow z największą liczbą próśb, a pokazuje je karta Wyniki zatwierdzeń (Approval outcomes) na dashboardzie.

Karta Workflows na dashboardzie sumuje to samo dla każdego workflow, który widzisz, w okresie ustawionym na dashboardzie: runy, błędy, koszt i pięć najczęściej uruchamianych. Nad nimi liczy runy, które czekają teraz na człowieka - na zatwierdzenie albo krok wymagający uwagi - niezależnie od tego, kiedy się zaczęły. Przez API to GET /api/v1/workflows/summary?from=2026-10-01&to=2026-10-31.

Run otwiera się na czasie trwania, koszcie (wydatek poniżej $0.0001 pokazuje się jako <$0.0001, nie zero) i liczbie wykonanych kroków, a potem na błędzie, którym się zakończył, jeśli taki był. Obok jest graf, który wykonał, narysowany tak, jak edytor rysuje run: plakietka każdego kroku, jego próby i błąd oraz wyszarzone kroki, do których nigdy nie dotarł. Rusza się tylko strona otwarta w trakcie runu; otwarta później jest nieruchoma. Open loop body pokazuje w ten sam sposób iteracje pętli.

Odpowiedź runa - jego tekst, wynik strukturalny, fragmenty, na których się oparł, i liczba utworzonych plików, z samym JSON-em pod Raw output - oraz każdy wykonany krok, iteracja po iteracji, są obok. Trwający run odświeża się co kilka sekund, a Cancel run go zatrzymuje i wycofuje liczniki, które ustawiły jego czekające kroki. Jego Files wymieniają to, co zapisały jego kroki - pobrany plik, wyrenderowaną stronę, wynik skryptu - każde do pobrania.

Run czekający na krok Ask for approval widać w zakładce Zatwierdzenia (Approvals) w Activity. Gdy krok ma ustawione Let the approver edit i powiązaną propozycję, na przykład przygotowaną odpowiedź, zatwierdzający zmienia ją tam w edytorze, z przyciskami Przywróć oryginał (Restore original) i Pokaż zmiany (Show changes), i zatwierdza swoją wersję. Krok przekazuje wtedy dalej final, original i edited, więc kolejny krok wysyła to, co osoba zatwierdziła. Decydujący, którego krok nie wskazuje, widzi propozycję tylko do odczytu, a prośba rozstrzygnięta ze zmienioną wersją ma pod Zdecydowane (Decided) znacznik Zmieniono (Edited).

Gdy krok wymienia Ways to approve, kolejka pokazuje po jednym przycisku na każdy, z etykietą, którą napisał autor, zamiast Approve; Reject zostaje. Każdy sposób jest portem wyjściowym kroku, więc workflow idzie dalej tym, który wybrał zatwierdzający, a zdecydowany wiersz go wymienia. Edycja idzie z dowolnym naciśniętym przyciskiem.

Na liście wersja testowego przebiegu to Draft (test), a prawdziwego Published, a przebieg uruchomiony z konsoli albo przez HTTP API ma Console or API. Status, Version, Started by i Started (ostatnia godzina, doba, tydzień albo 30 dni) zawężają przebiegi, a lista odpowiada po jednej stronie naraz; każdy filtr trafia do adresu, więc przefiltrowaną listę można podlinkować. Runs na liście workflow pokazuje przebiegi wszystkich workflow razem. Na stronie przebiegu kliknięcie kroku pokazuje jego Input i Output z tego przebiegu. Wiersze, które zapisał szybki log kroku, widać pod krokiem.

Retry from failed step uruchamia nowy przebieg tej samej wersji z tym samym wejściem, w którym każdy krok, który się udał, przekazuje to, co przekazał wcześniej, więc działa tylko nieudany krok i to, do czego nie doszedł, a zapis nigdy nie powtarza się dwa razy. Pętla działa ponownie i używa kroków każdego elementu, które się udały. Debug in editor przypina do kroków wersji roboczej to, co każdy krok poza pętlą przekazał w tym przebiegu, więc przebieg testowy zaczyna od miejsca, w którym tamten był. Przez API ponawia POST /api/v1/workflow-runs/{id}/retry, a GET /api/v1/workflow-runs przyjmuje status, mode, triggered_by, created_after i created_before.

Resolve pojawia się przy kroku wymagającym uwagi, dopóki jego run jest aktywny. Krok wymaga uwagi, gdy mógł zadziałać, a nikt nie widział jego końca, albo gdy przestał czekać i nic już go nie obudzi. Okno nazywa krok i mówi, o który przypadek chodzi. Run it again kolejkuje krok do nowej próby w tym samym runie, a przy kroku, który mógł coś zapisać, ostrzega, że to może zrobić to dwa razy. Treat it as failed to Take its error route, gdy krok kieruje swoje błędy albo leży w pętli, albo Fail the run. Jeśli krok zgłosił wynik po tym, jak go porzucono, Use that result idzie dalej od niego. Nic innego w runie nie jest ruszane, więc sąsiednie kroki, zatwierdzenia i timery toczą się dalej.

Krok może rozstrzygnąć tylko osoba, która uruchomiła run, albo edytor workflow, a w runie testowym tylko edytor może rozstrzygnąć krok albo ponowić run. Przez API służy do tego POST /api/v1/workflow-runs/{id}/steps/{node_run_id}/rerun z polem choice, a decyzja trafia do audytu. Run anulowany albo zakończony błędem nie ma kroku do rozstrzygnięcia: Retry from failed step uruchamia nowy run. Krok, który skończył się po zatrzymaniu runa, jest oznaczony Finished after the run stopped, a ponowienie go używa.

Strona Logs

Logs, w menu More w nagłówku edytora, wyświetla to, co szybkie logi workflow zapisały w jego przebiegach, od najnowszych: kiedy, krok, jego wynik i wiadomość. Zawęż wiersze po Step, Outcome i Written (ostatnia godzina, doba, tydzień albo 30 dni), przeszukaj wiadomości i włącz Include test runs - dopóki tego nie zrobisz, przebiegi testowe są pominięte. Aby zobaczyć wiersze jednego przebiegu, wklej jego identyfikator w polu Run albo wpisz kilka pierwszych znaków (co najmniej cztery); Show only this run przy wierszu wypełnia to pole, a See in Logs na stronie przebiegu otwiera log przefiltrowany do tego przebiegu. Wiersz otwiera przebieg, który go zapisał. W widoku przebiegu wiersze każdego kroku są pod nim, w kolejności zapisu. Klucz API organizacji z workflows:view też je odczytuje, dla runów o publicznym pochodzeniu: zob. Odczyt logu workflow.

Alerty

Alert informuje ludzi, gdy log zbyt często zapisuje coś konkretnego. Pod listą karta Alerts zawiera reguły workflow; Add alert otwiera nową. Reguła ma nazwę i liczy pasujące wiersze:

• Outcomes: wyniki, które się liczą, spośród tych, które zapisuje log wybranego kroku, plus error. Wiersz, który wyszedł kilkoma portami, pasuje do każdego z nich.
• Step: jeden krok albo każdy krok, który loguje.
• Message contains: opcjonalne słowa, dopasowywane bez względu na wielkość liter.
• Occurrences i Within: co najmniej tyle pasujących wierszy (od 1 do 1000) w ciągu 5, 15, 30 lub 60 minut, 4 godzin albo doby.

Reguła odpala się najwyżej raz na okno: po odpaleniu milczy przez długość swojego okna, potem liczy od nowa od tego momentu, a żaden wiersz nie jest liczony do dwóch odpaleń. Liczą się tylko prawdziwe przebiegi; wiersze przebiegu testowego nigdy nie wywołują alertu. Workflow ma do 25 reguł, a przełącznik przy każdej ją wstrzymuje.

Who is told to właściciel workflow, od którego zaczyna nowa reguła, administratorzy organizacji albo wskazane osoby; osoba, która opuściła organizację, jest pomijana. Każda z nich dostaje powiadomienie w dzwonku i e-mail, zgodnie z własnymi preferencjami powiadomień, a ten, kto nie może już zobaczyć workflow, nie widzi powiadomienia. Powiadomienie podaje, ile wierszy pasowało, a jego link otwiera stronę Logs przefiltrowaną do kroku i wyników reguły. Reguła z wynikiem, którego krok opublikowanej wersji nie ma, jest oznaczona na liście.

Reguły widzi każdy, kto może zobaczyć workflow; dodaje, zmienia, wstrzymuje i usuwa je każdy, kto może go edytować, przez rolę albo przez grant na nim. Reguły nie są częścią publicznego API.

Uruchamianie workflow spoza konsoli

Workflow może mieć kilka niezależnych wyzwalaczy, np. Manual, Webhook i Schedule. Dodanie wyzwalacza zachowuje dotychczasowe wejścia i ich połączenia. Run wybiera jedno wejście i wykonuje tylko osiągalną z niego gałąź; nie czeka na inny wyzwalacz. Wspólny krok może czytać wyłącznie dane dostępne z każdego wejścia, które do niego prowadzi. Różne formaty danych znormalizuj osobno przed wspólnymi krokami.

Publikacja aktywuje wszystkie skonfigurowane wejścia automatyczne z uprawnieniami publikującego. Workflow może mieć po jednym wyzwalaczu każdego rodzaju automatycznego. Ponowna publikacja zachowuje adresy i poświadczenia pozostawionych węzłów oraz usuwa skasowane rejestracje. Trigger w More pokazuje wszystkie opublikowane wejścia i ich opcje. Przełącznik Active w nagłówku wstrzymuje lub wznawia wszystkie rejestracje. Test draft pozwala wybrać wejście; API przyjmuje entry_node_id, ale rzeczywiste wywołanie może wybrać tylko Manual/API, nigdy wejście automatyczne.

Wersję, która startuje od Manual albo API request albo w ogóle bez wyzwalacza, uruchamia każdy, kto może ją uruchomić, jako on sam: Start a run w Runs, HTTP API albo WebSocket. Każdy run jest sprawdzany, rozliczany i audytowany tak samo jak uruchomiony tutaj. Te drogi nie uruchamiają żadnego innego wyzwalacza, a każdy inny wyzwalacz ma własną. Run testowy szkicu przyjmuje dowolny wyzwalacz, a Start a run otwiera go z wejściem w kształcie tego wyzwalacza.

Manual to wyzwalacz, który osoba uruchamia przyciskiem Test draft; API request to ten, który wywołuje system, a Trigger pokazuje jego endpoint i przykładowe żądanie. Daj któremuś pola wejścia, a run poprosi o to, czego potrzebuje: Test draft i Start a run pokazują formularz z jednym polem na każde pole zamiast JSON-a, z typem pola, a wywołanie API, którego wejście nie pasuje, jest odrzucane z listą błędnych pól. Zobacz core.input.

Z czatu

Wybór tego, kto odpowiada na czacie, wymienia pod agentami opublikowane workflow, które startują od Chat message. Gdy wybrany jest jeden z nich, każda wiadomość uruchamia jego run, a wyzwalacz przekazuje kolejnym krokom wiadomość jako prompt, razem z conversation_id i user_id nadawcy. Wątek pokazuje kartę ze statusem runa i linkiem do jego kroków, a odpowiedź workflow pojawia się pod nią, gdy run się skończy.

Odpowiedź jest zapisywana w rozmowie, gdy run się kończy, niezależnie od tego, czy czat jest jeszcze otwarty, więc ponowne otwarcie rozmowy ją odczytuje. Run pisze do rozmowy, z której został uruchomiony, i nigdzie indziej: dotarcie do kogokolwiek innego wymaga kroku HTTP albo powiadomienia w grafie.

Open chat w nagłówku edytora pozwala wypróbować szkic zaczynający się od wiadomości czatu bez wychodzenia z niego. Każda wiadomość wysłana w panelu uruchamia testowy run szkicu z tą wiadomością, run otwiera się na płótnie, a jego odpowiedź - tekst kroku Output - pojawia się pod wiadomością. To testowe runy bez rozmowy, do której mogłyby odpowiedzieć, więc nic z panelu nie trafia do prawdziwego czatu. New chat zaczyna od nowa z nowym id rozmowy.

Przez WebSocket

/api/v1/ws/workflow-runs uruchamia run i strumieniuje jego zdarzenia albo śledzi run, który już trwa. Klient, który stracił połączenie, łączy się ponownie z kursorem ostatniego zdarzenia, które widział, i podejmuje dokładnie tam, gdzie przerwał. Zdarzenia są zapisywane, zanim zostaną wysłane, więc nic nie ginie i nic nie uruchamia się dwa razy. Gniazdo ponownie sprawdza sesję i dostęp członka przed każdą ramką i każdym odczytem strumienia. Ramki opisuje HTTP API.

Webhook albo harmonogram

Wyzwalacz Webhook dostaje adres i signing secret przy pierwszej publikacji wersji, która go zawiera. Publikacja pokazuje sekret raz, a kolejne publikacje tego samego węzła zachowują oba; węzeł webhooka usunięty i dodany ponownie dostaje nowy adres. Nadawca podpisuje sekretem dokładną treść żądania, HMAC-SHA256 w X-Signature-256, i nazywa każde dostarczenie w X-Delivery-Id; własne nagłówki GitHuba też działają. Wyzwalacz przekazuje JSON dostarczenia jako body, razem z jego delivery_id. Ponowienie, które powtarza id, dostaje odpowiedź z pierwszym runem i niczego nie uruchamia, bo id jest zapisywane razem z runem, który wpuściło, w jednej transakcji.

Wyzwalacz Schedule uruchamia się co jakiś czas, codziennie o ustalonej godzinie albo według wyrażenia cron, w strefie czasowej workflow (UTC, chyba że jego Settings wskazują inną) i najczęściej raz na minutę. Rusza w swoim tyknięciu, a nie przy następnym przeglądzie po nim. Jego Input to to, od czego zaczyna każdy run, przekazywane jako input obok fired_at danego tyknięcia. Tyknięcie, które zastaje poprzedni run wciąż trwający, jest pomijane, zamiast ustawiać za nim drugi run, a tyknięcie odrzucone przez limit przyjęć czeka na następne.

Oba działają jako członek, który opublikował wersję, a jego dostęp jest sprawdzany od nowa przy każdym odpaleniu. Webhook, którego członek nie może już uruchomić workflow, odrzuca dostarczenia, a taki harmonogram jest wyłączany i odnotowywany w dzienniku audytu. Pause w arkuszu Trigger zatrzymuje każdy z nich bez publikacji, a New secret wymienia sekret webhooka; stary od razu przestaje przechodzić weryfikację.

Treść webhooków jest ograniczana podczas strumieniowania, również bez Content-Length. Testowe dostarczenie ma limit przypiętych danych 64 KB; webhooki produkcyjne i GitHub używają WORKFLOW_RUN_MAX_INPUT_BYTES. Odpowiedzi webhooka o statusie 204, 205 lub 304 nie mają treści, zgodnie z HTTP, ale zachowują dozwolone nagłówki. Konwersja PDF do obrazów odrzuca dokumenty ponad 2 000 stron przed odczytaniem rozmiarów stron, nawet gdy wybrano tylko jedną stronę.

Gdy rekord tabeli zostanie dodany, zmieniony lub usunięty

Wyzwalacz Table record wskazuje tabelę, zdarzenia rekordu (events), od których startuje - dodanie, zmiana, usunięcie - oraz filtry na rekordzie takim, jaki został dodany lub zmieniony, albo jaki był przed usunięciem, z konsoli, API, od agenta lub z kroku tabeli innego workflow. Zmiana uruchamia go tylko wtedy, gdy zmieniła się wybrana kolumna, o ile kolumny tabeli są wybrane.

Przekazuje rekord: record_id, event, values według id kolumn, te same wartości jako fields według etykiet, wybór jako etykietę opcji, before i kolumny changed przy zmianie lub usunięciu oraz author_id osoby, która to zrobiła. Publikacja wymaga dostępu do odczytu tabeli, a nic, co stało się przed publikacją, go nie uruchamia.

Run uruchomiony w ten sposób niesie łańcuch wyzwalaczy, przez które przeszedł, więc workflow zapisujący z powrotem do tabeli, której wyzwalacz go uruchomił, jest blokowany zamiast się zapętlić.

Triggers samej tabeli wymienia workflow, które od niej startują, wstrzymuje je i wznawia oraz pokazuje, co każdy zdecydował o każdym rekordzie. Zobacz Virtual Tables.

Z formularza

Test draft otwiera podgląd formularza po zalogowaniu dla pojedynczego triggera Form. URL wskazuje konkretny node, więc niezależne formularze mają osobne podglądy. Wysłanie odpowiedzi uruchamia test zapisanego szkicu; otwórz run, aby sprawdzić wynik. Podgląd nie publikuje linku publicznego. Użytkownik z prawem odczytu może obejrzeć stronę, ale nie wykonać szkicu.

Krok Form pokazuje link testowy i opublikowany przy konfiguracji. Wygląd ustawia akcent, standardową lub szeroką stronę oraz kartę lub prosty układ. Podgląd wyglądu korzysta z tego samego renderera co strona publiczna. Opis obsługuje Markdown; pola, tekst przycisku i komunikat po wysłaniu są konfigurowalne. Test może wykonać akcje workflow.

Wyzwalacz Form daje workflow publiczną stronę: tytuł, opis i jedno pole na każde zadeklarowane pole, typowane tak jak pola Manual, z własnymi słowami na przycisku i po wysłaniu. Publikacja tworzy stronę, a Trigger pokazuje link do skopiowania lub otwarcia. Każdy z linkiem wypełnia ją bez logowania, a każda odpowiedź pasująca do pól uruchamia jeden run jako członek, który opublikował formularz. Kolejne kroki czytają odpowiedzi jako payload, a strona runów mówi, że uruchomił go formularz.

Link jest jedynym poświadczeniem strony i przetrwa każdą publikację tego samego węzła. New link go zastępuje, a stary odpowiada wtedy tak, jakby formularza nie było; wstrzymanie wyzwalacza zamyka stronę. Odpowiedzi, które nie pasują, są wskazane na stronie i niczego nie uruchamiają, ukryte pole łapie skrypty, a każdy formularz przyjmuje najwyżej RATE_LIMIT_FORM_SUBMISSIONS_PER_MINUTE odpowiedzi na minutę. Zobacz trigger.form.

Z GitHuba

Wyzwalacz GitHub uruchamia workflow, gdy coś dzieje się w jednym repozytorium: zgłoszenie, komentarz, pull request lub jego recenzja, push, wydanie albo przebieg Actions - to, co wskazuje Starts on, i tylko wymienione actions, takie jak opened, jeśli jakieś są. Publikacja daje mu własny adres i sekret podpisu. Gdy Set up the webhook for me jest włączone, a konto GitHub organizacji jest podłączone z uprawnieniem do zarządzania webhookami, publikacja rejestruje hook w repozytorium i rejestruje go ponownie przy każdej kolejnej publikacji; w przeciwnym razie raz pokazuje sekret do wklejenia razem z adresem z Trigger w Settings > Webhooks repozytorium.

Każda dostawa podpisana przez GitHub dla tego repozytorium, zdarzenia i akcji uruchamia run jako członek, który opublikował workflow, z event, action, repository, sender i całym payload. Ponowna dostawa odpowiada pierwszym runem, a wszystko inne - łącznie z ping GitHuba - jest pomijane. New secret zastępuje sekret i ponownie rejestruje hook tam, gdzie założyło go konto. Zobacz trigger.github.

Z e-maila

Wyzwalacz Gmail uruchamia workflow, gdy do skrzynki Gmail organizacji - tej podłączonej przez portal Gmail - przyjdzie wiadomość. Panel kroku mówi, czy skrzynka jest podłączona, i pozwala ją podłączyć, a publikacja jest odrzucana, dopóki nie jest. Skrzynka jest czytana tym samym odczytem, który uruchamia wyzwalacze Gmail agentów, co minutę, a każda nowa wiadomość pasująca do wszystkich ustawionych filtrów - Subject contains i Sender contains bez względu na wielkość liter oraz Label dokładnie - uruchamia run jako członek, który opublikował workflow.

Check for new mail every w bloku skrzynki w kroku zmienia ten takt (1, 5, 15, 30 lub 60 minut). To ustawienie skrzynki i dotyczy każdego triggera na niej.

Sender contains czyta adres nadawcy, nigdy nazwę wyświetlaną: @acme.com pasuje dokładnie do tej domeny, a nie do jej poddomen, pełny adres pasuje do tego adresu, a inny tekst do fragmentu adresu. Gdy jest ustawiony, wiadomość musi też przejść sprawdzenie uwierzytelnienia nadawcy - DMARC zakończony powodzeniem albo podpis DKIM domeny nadawcy - więc From, który każdy może wpisać, nie uruchamia runa. Wiadomości z etykietą SENT, DRAFT, SPAM lub TRASH nie są nowymi wiadomościami i niczego nie uruchamiają, chyba że Label wskazuje jedną z nich.

Run dostaje sender, to, subject, text, snippet, labels i message_id skrzynki oraz wątek, do którego wiadomość należy: thread_id, rfc_message_id (nagłówek Message-ID), in_reply_to, references, received_at i treść html. Trzy pola nagłówkowe pisze nadawca, więc pozwalają powiązać odpowiedź z wątkiem, ale nic nie dowodzą o tym, kto wysłał wiadomość. Wiadomość przeczytana dwa razy uruchamia run raz, a ta, dla której organizacja nie miała jeszcze miejsca, jest czytana ponownie minutę później. Zobacz trigger.gmail. Aby odczytać treść html jako tekst, linki albo to, co wybiera selektor CSS, powiąż ją z html.parse.

Wyzwalacz Outlook robi to samo dla skrzynki Microsoft 365 organizacji, podłączonej przez portal Outlook. Microsoft Graph jest czytany folder po folderze, więc krok wskazuje Folder, który obserwuje - domyślnie skrzynkę odbiorczą - oraz, aby czytać skrzynkę współdzieloną, którą podłączone konto może otworzyć, Shared mailbox. Filtry to Subject contains, Sender contains, Has attachments, Importance i Category. Pierwszy odczyt folderu zaczyna się od chwili opublikowania lub ostatniego włączenia workflow, więc poczta, która już tam leży, niczego nie uruchamia.

Wskazanie skrzynki współdzielonej, którą otwiera grant Microsoft organizacji, wymaga uprawnienia do zarządzania połączeniami, tak jak w triggerach agentów Outlook; workflow, który już nasłuchuje takiej skrzynki, zachowuje ją przy kolejnych publikacjach, a jej zmiana znowu wymaga tego uprawnienia. Jeśli Outlook zgłosi, że folderu nie da się już czytać, workflow jest wyłączany, a dziennik audytu podaje powód. Run dostaje te same pola co run z Gmaila, przy czym labels zawiera kategorie wiadomości, a mailbox skrzynkę współdzieloną, z której przyszła. Zobacz trigger.outlook.

Oba wyzwalacze poczty przyjmują dane z zewnątrz: każdy może wysłać wiadomość do skrzynki, więc to, co run z nią robi, wiąż tak jak dla webhooka.

Pole attachments wiadomości wymienia nazwę, zadeklarowany typ i rozmiar każdego pliku; skrzynka podaje najwyżej 20 na wiadomość, a treść text lub html jest czytana do 20 000 znaków. Run uruchomiony przez skrzynkę zapisuje je jako pliki runa, a każdy dostaje file i stored: true. Z wymienionych załączników brane jest pod uwagę tylko pierwsze 10, do 25 MiB łącznie, a każdy musi mieścić się w limicie rozmiaru uploadu czatu, na liście dozwolonych typów plików i w limicie miejsca organizacji.

Pominięty załącznik ma reason: too_many (poza pierwszymi 10), too_large, type_not_allowed, quota albo unreadable - skrzynka odpowiedziała na niego kodem 400, 401, 403 lub 404 albo jej grant jest brakujący, wyłączony lub nie da się go odnowić. Testowy run niczego nie czyta ze skrzynki, więc jego załączniki mają not_fetched. Gdy skrzynka zawodzi w sposób, który ponowienie może naprawić, krok kończy się błędem MAIL_ATTACHMENT_UNREACHABLE i jest ponawiany.

Z wiadomości na kanale

Wyzwalacz Channel message przekazuje workflow wiadomości do bota na Slacku, Mattermost lub Telegramie. Każda wiadomość, na którą bot odpowiedziałby własnym agentem - przeszła politykę dostępu bota, jej nadawca został dopuszczony, a na kanale wskazała bota - uruchamia run jako członek, który opublikował workflow, jeśli pasuje do Where i Only when the message contains. Wiadomość wskazująca agenta przez @handle nadal trafia do niego, a ta, która nie pasuje, dostaje odpowiedź od agenta bota jak dotąd, więc workflow może przejąć zwroty i zostawić resztę.

Wyzwalacz przekazuje text, sender - z członkiem, którego nadawca powiązał, jeśli to zrobił - oraz channel_id i thread_id, które przyjmuje krok Send a message tej samej platformy, więc odpowiedź trafia do wątku, z którego przyszła wiadomość. Wyzwalacze Slacka i Mattermost przekazują wątek nawet przy wiadomości z najwyższego poziomu, bo sama wiadomość go zakłada, więc powiązana odpowiedź jest w wątku; wyzwalacz Telegrama przekazuje temat tylko wewnątrz tematu forum.

Krok Send a message dodany po triggerze Channel message startuje jako bot tego triggera, z powiązanymi channel_id i thread_id, gdy platformy się zgadzają. Wiadomości jednego bota uruchamiają najwyżej jeden workflow, a nasłuchiwanie bota wymaga channels:manage. Notatka głosowa przychodzi jako transkrypcja; inne załączniki nie są przekazywane. Zobacz trigger.channel_message.

Gdy wywołuje go inny workflow

Wyzwalacz Called by a workflow tworzy workflow, który inne uruchamiają jako krok: wspólna logika - wzbogacenie leada, założenie zgłoszenia - trzymana w jednym miejscu. Deklaruje pola tak jak Manual, a krok Run a workflow innego workflow, który oferuje tylko tak opublikowane workflow, uruchamia go z powiązanym wejściem, sprawdzonym najpierw względem tych pól.

Krok czeka na wywołany przebieg i przekazuje jego output albo od razu idzie dalej, gdy Wait for it to finish jest wyłączone. Wywołany przebieg jest powiązany z wywołującym w obie strony - jego strona mówi Called by ten przebieg, a wiersz kroku na stronie wywołującego otwiera przebieg, który krok uruchomił - i widać go na stronach przebiegów jak każdy inny. Przebieg uruchomiony przez workflow błędów mówi, niepowodzenie którego przebiegu go uruchomiło. Wywołanie z powrotem workflow, który już działa w łańcuchu, albo głębsze niż pięć wywołań, zostaje odrzucone.

Wywołany workflow dziedziczy pozostały budżet przebiegu nadrzędnego i wcześniejszy termin zakończenia. Jego koszt powiększa koszt nadrzędny; own_cost podaje wyłącznie bezpośrednie opłaty danego przebiegu, aby sumowanie rekordów nie liczyło ich podwójnie. Przy skończonym budżecie opcja oczekiwania na zakończenie musi pozostać włączona. Anulowanie przebiegu nadrzędnego lub odebranie mu dostępu zatrzymuje podproces przed kolejnym krokiem; rozpoczęte żądanie zewnętrzne może się zakończyć. Ponowienie wywołania korzysta z udanych kroków pierwotnej, zamrożonej wersji podprocesu. Jeśli podproces nadal działa, trzeba go najpierw zakończyć lub zatrzymać. Pliki wynikowe są jawnie importowane do przebiegu nadrzędnego, a wznowienie oczekiwania ponownie sprawdza dostęp.

Wykres dzienny i statystyki kroków przebiegu nadrzędnego także obejmują opłaty podprocesu.

Odzyskiwanie zatrzymuje się, gdy udany krok utracił wynik albo wywołany przebieg usunięto lub jego historia ponowień zawiera cykl. Nie powtarza efektów, aby odtworzyć tę historię. Anulowanie podprocesu, wyczerpanie budżetu i odebranie uprawnień także pozostają błędami, których gałąź obsługi błędów nie może ukryć.

Z agenta

Nowe narzędzia agenta konfiguruj przez serwer AgenticOS MCP, wybierając potrzebne narzędzia odkrywania workflow, run_workflow i odczytu wykonania. Zadeklarowane wejście opublikowanego workflow przekaż jako fields; odczytuj zwrócony run do zakończenia. MCP używa uprawnień pytającej osoby i zachowuje zatwierdzanie zapisów. Agent działający wewnątrz workflow wywołuje inny workflow przez krok workflow.run. Istniejące bindings Workflows pozostają zgodne: zachowują jawne identyfikatory workflow, limit oczekiwania i granty akcji opublikowanych stron.

Run, za którym nie stoi żaden członek (odwiedzający widget, embed albo hostowaną stronę, niepowiązany nadawca z kanału, dostarczenie triggera zdarzeniowego agenta), niczego nie uruchamia.

Z aplikacji

Opublikowana strona może uruchomić workflow, który jej agent powiązał i który startuje od Manual albo API request. Strona tylko prosi. Członkowi, który ją ogląda, pojawia się okno z nazwą samego workflowu i każdą wartością wejścia, a run startuje dopiero po jego potwierdzeniu. Jest jego: jego dostęp, jego budżet i jego strona runów, sprawdzane, rozliczane i audytowane jak run uruchomiony przez Start a run, z tą samą kwotą przyjęć. Run bez członka za sobą albo z sesji impersonowanej niczego nie uruchamia.

Strona runów podaje, że taki run uruchomiła A page, a filtr Started by pozwala po tym filtrować; w API jego triggered_by to app. Run zapisuje też stronę i wersję, na którą członek patrzył, a ponowienie je zachowuje. Strona odczytuje tylko status runa, jego odpowiedź i pierwszy wiersz błędu.

Gdy inny workflow zawiedzie

Wyzwalacz On failure of a workflow tworzy workflow błędów. Wybrany jako workflow błędów innego workflow w jego Settings, uruchamia się raz dla każdego prawdziwego przebiegu tamtego workflow, który zakończy się niepowodzeniem, z run_id przebiegu, jego workflow_id i workflow_name, step_id i step_name kroku, który zawiódł, oraz error, którym się zakończył. Działa jako członek, który go wybrał i który nadal musi móc go uruchomić. Przebieg testowy niczego nie uruchamia, podobnie jak porażka przebiegu, który sam jest workflow błędów, więc zawodzący workflow błędów nigdy nie uruchamia się ponownie.

Gdy coś pójdzie nie tak

Co obiecuje run. Wynik kroku i wysłanie kroków po nim zapisują się razem, więc worker, który zatrzyma się między krokami, niczego nie gubi: inny podejmuje run tam, gdzie był. Worker, który zatrzyma się w środku kroku, zostawia próbę, której końca nikt nie widział. Krok bezpieczny do powtórzenia jest ponawiany. Zapis do tabeli odtwarza swój pierwszy zapis przez potwierdzenie zamiast zapisywać drugi raz, a powiadomienie idzie raz. Krok, który mógł już zadziałać gdzie indziej i niczego więcej nie obiecuje - jak uruchomienie agenta - nigdy nie jest powtarzany sam: run zatrzymuje się jako Wymaga uwagi, żeby nikt nie zapłacił za model dwa razy ani nie wysłał wiadomości dwa razy, zanim ktoś o tym zdecyduje.

Nic innego nie dzieje się dokładnie raz. Wywołanie HTTP, upload albo zapis pliku mogą zostać wykonane ponownie po takim zatrzymaniu, więc system odbierający, który nie może zobaczyć żądania dwa razy, potrzebuje własnego klucza idempotencji. Obietnica ponowień każdego kroku jest w referencji węzłów.

Co widzisz	Dlaczego	Co zrobić
Wymaga uwagi	Przerwano krok, który mógł zadziałać, albo przestał czekać i nic go nie obudzi	Sprawdź, czy jego efekt nastąpił, a potem użyj Resolve na kroku w runie: uruchom go ponownie, użyj wyniku zgłoszonego późno, przejdź jego ścieżką błędu albo zakończ run błędem. Anulowanie runa, a potem Retry from failed step, zaczyna od nowa
PRINCIPAL_REVOKED	Członek, jako który działa run, stracił dostęp albo jego konto dezaktywowano	Niech członek, który może uruchamiać workflow, opublikuje go ponownie, żeby jego wyzwalacz działał jako on
WORKFLOW_TRIGGER_MISMATCH	Run zażądano drogą, którą nie jest żywy wyzwalacz: ręcznie albo przez API dla workflow startującego od webhooka, albo na czacie dla takiego, który nie startuje od wiadomości na czacie	Uruchom go tak, jak mówi jego wyzwalacz, albo przetestuj szkic, który przyjmuje dowolny wyzwalacz
INVALID_BINDING	Wartość nie pasowała do pola, do którego ją zbindowano	Błąd kroku wskazuje pole; popraw binding albo wartość wcześniej w grafie
REVISION_CONFLICT	Ktoś zmienił rekord po tym, jak krok go odczytał	Skieruj błąd kroku przez error.handle do świeżego odczytu
Historia wyzwalacza tabeli mówi Zablokowany	Run uruchomiłby sam siebie ponownie albo jego łańcuch sięgnął za głęboko	Zobacz Wyzwalacze
Webhook odpowiada 403	Podpis nie pasuje do treści albo członek, jako który działa, nie może już uruchamiać workflow	Podpisz dokładnie wysłane bajty bieżącym sekretem albo niech członek, który może go uruchamiać, opublikuje go ponownie

Klawiatura i dostępność

Każda część edytora ma drogę, która nie wymaga wskaźnika. Wybór kroków to lista, po której poruszasz się strzałkami i wybierasz Enterem, a kliknięcie węzła w nim dodaje go bez przeciągania, każdy element sterujący z samą ikoną nosi wypowiadaną etykietę, a kanwa przyjmuje fokus klawiatury, więc możesz przechodzić tabem po jej krokach i połączeniach. Połączenie da się wykonać z klawiatury: zacznij je przy węźle, a potem zakończ przy zgodnym celu.

Skróty kanwy działają tylko wtedy, gdy fokus jest w edytorze, więc nigdy nie kradną klawisza polu gdzie indziej na stronie:

Przeciągaj lewym przyciskiem myszy, aby zaznaczać obiekty. Przytrzymaj Shift podczas przeciągania, aby przesuwać widok; środkowy i prawy przycisk również przesuwają widok. Ctrl/Cmd + A zaznacza wszystkie obiekty w bieżącym obszarze, w tym notatki na poziomie głównym.

Obserwowane wykonania pokazują ruchomy impuls prowadzący do aktywnego kroku i przesuwające się podświetlenie jego ramki. Krótkie podświetlenie zakończenia pomaga odczytać szybkie wykonania bez zmieniania ich rzeczywistego statusu lub czasu. Historyczne wykonania pozostają nieruchome, a systemowe ograniczenie animacji wyłącza ruch. Czas trwania, koszt i liczba ukończonych kroków są wyrównane w podsumowaniu, z czasem startu obok statusu.

Klawisze	Robi
Tab	Otwórz wybór kroków
Ctrl/Cmd + Enter	Uruchom testowo szkic, gdziekolwiek na stronie jest fokus
Ctrl/Cmd + Z	Cofnij
Ctrl/Cmd + Shift + Z lub Ctrl/Cmd + Y	Ponów
Ctrl/Cmd + C	Kopiuj zaznaczenie
Ctrl/Cmd + X	Wytnij zaznaczenie
Ctrl/Cmd + V	Wklej, przesunięte, tak by nie zakrywało oryginału
Delete lub Backspace	Usuń zaznaczenie
Escape	Przerwij trwające połączenie
?	Pokaż te skróty

Wklejenie dostaje świeże id i przemapowuje bindingi wśród skopiowanych kroków, więc wklejone kroki czytają od siebie nawzajem, a nie od oryginałów. Każdy skrót edycji jest bezczynny, gdy edytor jest tylko do odczytu - w opublikowanej wersji albo w trybie View only; Escape wciąż przerywa zabłąkane połączenie, a ? wciąż pokazuje skróty.

Kopiowanie i wklejanie mają trzy ograniczenia:

• Krok z bindingami czyta stamtąd, skąd czytał. Skopiowany krok zachowuje swoje bindingi. Ten, który czyta z kroku, którego nie skopiowałeś, wciąż czyta z oryginału, ale nic nie łączy wklejonego kroku z tamtym, więc nie przejdzie walidacji, dopóki ich nie połączysz. Zaznacz oba kroki, aby skopiować parę, a kopia będzie czytać z własnego kroku poprzedzającego.
• Połączenie podróżuje tylko ze swoimi dwoma krokami. Zaznaczenie samego połączenia i skopiowanie niczego nie robi.
• Skróty należą do kanwy. Działają, gdy fokus jest na kanwie, a kliknięcie w dowolnym jej miejscu — w krok, pustą kanwę, połączenie — go tam zatrzymuje. Fokus w ustawieniach kroku lub w wyborze kroków zostawia klawisze tamtym polom, więc kliknij kanwę, zanim ich użyjesz.

Załączniki obrazów agenta mają wspólny limit 20 MB, sprawdzany przed odczytem każdego pliku, również dla powtórzonych referencji. Wyniki MCP usuwają nagłówki uwierzytelnienia i poświadczenia z tekstu oraz zagnieżdżonych danych. Nazwy plików są normalizowane przed zapisem, z zachowaniem rozszerzeń i limitu 255 znaków. Pola CSV mieszczą się w limicie bajtów kroku, do 50 MB; odmowy parsera mają jawny typ.

Pętla mierzy w SQL najnowsze wyniki yield i nieobsłużone błędy przed ich pobraniem. WORKFLOW_FOREACH_MAX_OUTPUT_BYTES domyślnie wynosi 10 MiB, łącznie z narzutem kolekcji; przekroczenie daje FOREACH_OUTPUT_TOO_LARGE. Dla dużych wyników zwracaj mniejsze wartości lub referencje plików. Kolizja klucza podsumowania z polem grupy kończy się SUMMARY_KEY_COLLISION.

Wejścia przebiegów, konfiguracje draftów i przypięte wyniki muszą mieścić się w formacie JSONB PostgreSQL. Niezapisywalny wynik węzła daje INVALID_NODE_OUTPUT, bez automatycznego ponowienia i z zachowaniem poniesionych kosztów. Zewnętrzna operacja mogła już się zakończyć; sprawdź ją przed ręcznym powtórzeniem węzła.

Wyniki węzła mają wspólny limit WORKFLOW_NODE_MAX_OUTPUT_BYTES (domyślnie 10 MiB): wynik próby, wyjście runa i odpowiedź webhooka łącznie. Przekroczenie daje NODE_OUTPUT_TOO_LARGE, zachowuje koszty i nie uruchamia automatycznego retry. Split out sprawdza liczbę po rozwinięciu (maks. 10 000) przed kopiowaniem oraz konserwatywnie szacuje rozmiar powielonych pól. Przekroczenie daje SPLIT_OUTPUT_TOO_LARGE. Większe dane przekazuj przez referencje plików.

Kontrola płytkiej projekcji pól modelu odrzuca też powielone duże wartości przed skopiowaniem całego wyniku przez serializację.

Socket workflow zachowuje tożsamość klucza organizacji i jego zakresy przy każdej klatce oraz odczycie strumienia. Klucz tylko do podglądu nie uruchamia runów; klucze nie śledzą prywatnych przebiegów człowieka ani nie piszą w osobistych czatach. Run zachowuje ograniczenia klucza dla workera, a cofnięcie klucza zamyka strumień przy następnym odczycie.

Galerie skills i kontekstu agenta w kroku pobierają wszystkie strony metadanych i pozwalają ponowić nieudany odczyt. Nowe wejścia evali mają limity JSONB i bajtów jak uruchomienie; starsze zbyt duże przypadki pozostają czytelne do usunięcia. Nieudany pakiet plików PDF lub sandboxa usuwa wcześniejsze zapisy tego pakietu, zachowując istniejące pliki. Skrypt zgłaszający błąd nadal zachowuje log diagnostyczny.

Podsumowanie

• Workflow to draft, który edytujesz, i opublikowana, niezmienna wersja, która działa — zacznij go od wyzwalacza lub z szablonu, a Duplicate kopiuje draft do nowego workflow.
• Wybór kroków dodaje kroki - z +, z wyjścia kroku albo prawym przyciskiem; kanwa je łączy i odrzuca połączenie między niezgodnymi portami.
• Krawędź ustala kolejność, a bindingi niosą wartości; połączenie portów o tym samym kształcie tworzy bindingi za Ciebie.
• Parametr to wartość albo dane z kroku — Data czyta je z osiągalnego, zgodnego typem wyjścia wcześniejszego kroku albo wstawia je do tekstu.
• Draft zapisuje się sam, a edycja z dwóch miejsc podnosi banner z Overwrite lub Reload.
• Publish jest zablokowany, dopóki problem istnieje, i waliduje ponownie na serwerze; wcześniejsze wersje pozostają widoczne tylko do odczytu, a Restore to draft robi z jednej z nich z powrotem draft.
• Każda akcja ma drogę klawiaturową, a skróty edycji są bezczynne na opublikowanej wersji tylko do odczytu i w trybie View only.
• Workflow może mieć kilka niezależnych wyzwalaczy, np. Manual, Webhook i Schedule. Dodanie wyzwalacza zachowuje dotychczasowe wejścia i ich połączenia. Run wybiera jedno wejście i wykonuje tylko osiągalną z niego gałąź; nie czeka na inny wyzwalacz. Wspólny krok może czytać wyłącznie dane dostępne z każdego wejścia, które do niego prowadzi. Różne formaty danych znormalizuj osobno przed wspólnymi krokami.
• Polityka kroku ustala jego próby, limit czasu i to, czy jego błędy wychodzą portem Error; ciało kroku For each wykonuje się od Loop item do Loop result raz na każdy element.
• Runs wymienia każdy run, Start a run testuje draft albo uruchamia opublikowaną wersję, a run pokazuje swój graf krok po kroku tak, jak przebiegł.

Nową automatyzację można przekazać przez prepare_workflow_draft: jedna akceptacja tworzy prywatną tabelę i kompletny graf w jednej transakcji. Błąd walidacji wycofuje oba zasoby. check_workflow_draft sprawdza graf i odwołania do zasobów bez uruchamiania kroków i bez akceptacji zapisu. Jawnie informuje, że integracje pozostają niezweryfikowane. Testy wykonujące akcje nadal wymagają zgody; test harmonogramu przyjmuje zwykłe dane i automatycznie dodaje czas zdarzenia oraz skonfigurowane wartości. Widok runa odróżnia test szkieletu od weryfikacji integracji.