Maszyna stanów w automatyzacji

Maszyna stanów to sposób projektowania procesu, w którym każda sprawa znajduje się w jednym nazwanym stanie, a system zna dozwolone przejścia do następnych stanów. Nie jest to tylko diagram dla programisty. To prosty kontrakt biznesowy: lead może być nowy, zakwalifikowany, oczekujący na odpowiedź, gotowy na ofertę albo zamknięty. Automatyzacja powinna odczytać aktualny stan przed akcją i zmienić go dopiero po udanym wyniku. Dzięki temu proces sprzedaży, obsługi klienta czy publikacji contentu staje się kontrolowanym przepływem, a nie zbiorem luźnych triggerów.

W odróżnieniu od listy zadań stan mówi, co już jest prawdą o obiekcie i co system może zrobić dalej. Zadanie „wyślij follow-up” może się pojawić kilka razy, ale stan „oczekiwanie na odpowiedź po follow-upie” jasno blokuje kolejną wysyłkę. Przejście powinno mieć warunek oraz skutek. Przykład: z „nowy lead” do „kwalifikacja” przechodzisz po odebraniu kompletnego formularza, a z „kwalifikacja” do „oferta” tylko gdy spełnione są kryteria i osoba wyraziła zainteresowanie. Nie zakładaj, że każdy rekord musi przejść wszystkie etapy.

Dokumentacja AWS Step Functions opisuje workflow jako maszynę stanów z krokami sterującymi przepływem oraz krokami wykonującymi pracę. Ten sam model sprawdza się bez AWS i bez kodu. W n8n możesz reprezentować stan w CRM, bazie danych lub danych workflowu, a warunki rozdzielające wykorzystać jako przejścia. Ważne jest, by stan krytycznej sprawy zapisywać trwale poza pojedynczym uruchomieniem. Jeżeli workflow zatrzyma się po wysłaniu wiadomości, następne uruchomienie musi wiedzieć, czy wiadomość faktycznie już poszła.

Praktyczny przykład dla eksperta: po zapisie na konsultację workflow tworzy lead w stanie „nowy”. Walidator sprawdza wymagane dane i przeprowadza go do „do kwalifikacji”. Agent AI może przygotować streszczenie formularza, ale nie zmienia samodzielnie stanu na „oferta”. Dopiero decyzja według ustalonych kryteriów lub akceptacja człowieka tworzy przejście. Po wysłaniu oferty stan brzmi „oczekiwanie na decyzję”, co uruchamia jeden follow-up po określonym czasie. Odpowiedź „nie teraz” prowadzi do osobnego stanu nurture, a nie do przypadkowego ponownego wysłania tej samej oferty.

Zaprojektuj najpierw małą liczbę stanów biznesowych, nie nazwy technicznych node’ów. Dla każdego zapisz: kto lub co może go ustawić, jakie dane są wymagane, do których stanów można przejść, co oznacza sukces i co robisz przy błędzie. Dodaj stany końcowe, takie jak wygrany, przegrany, anulowany lub wymagający ręcznej decyzji. Stan błędu nie powinien znikać w logu. n8n zaleca osobny workflow błędów, który uruchamia się przy nieudanym wykonaniu. Połącz go z powiadomieniem i identyfikatorem sprawy, aby błąd trafiał do właściwego etapu procesu.

Maszyna stanów nie zastępuje idempotencji. Sieć i webhooki mogą dostarczyć to samo zdarzenie więcej niż raz, a retry po błędzie może ponowić akcję. Przed przejściem sprawdź identyfikator zdarzenia i aktualny stan, a po sukcesie zapisz wynik atomowo, gdy używany system to umożliwia. Jeśli wysłanie e-maila jest nieodwracalne, najpierw zapisz zamiar i klucz idempotencji, a dopiero potem wyślij. W przeciwnym razie dwa równoległe uruchomienia mogą odczytać ten sam stan i wykonać dwa follow-upy.

Najczęstsza porażka to modelowanie wszystkiego jako jednego pola „status” bez reguł przejścia. Wtedy każdy workflow może przeskoczyć sprawę z nowego leada prosto do wygranego albo nadpisać ważną decyzję. Drugi błąd to zbyt drobiazgowe stany, które opisują każdy klik i utrudniają pracę. Zacznij od etapów, które zmieniają decyzję biznesową lub dostępne akcje. Agent AI może sugerować klasyfikację, ale przy kosztownych decyzjach i komunikacji z klientem zachowaj walidację oraz człowieka w pętli.