Marketing automation Form Handler zwraca „field required” a wszystko jest wypełnione – checklist debug

Kiedy dane wysyłają się, ale system marketing automation „nie widzi”

Sytuacja z jednego z projektów: formularz WordPress wysyła 13 pól do endpointa marketing automation. Wszystkie mają wartości. Wszystkie mają nazwy zgodne z Field Mappingiem w systemie marketing. A system po każdym submicie zwraca w odpowiedzi:

errorMessage: Please correct the following errors: - This field is required
allFields: [PUSTE]
errors: true

Klucz jest tam gdzie nie zwrócisz uwagi na pierwszy rzut oka: allFields jest puste. Nie ma listy pól które system rozpoznał. Nie ma listy pól które odrzucił. Nic. Tak jakby żadne pole nie doszło do handlera – a przecież POST przechodzi z 200 OK.

Kilka godzin debugowania później okazało się, że problem nie był w formularzu WordPressa. Był w konfiguracji systemu marketing automation po stronie klienta. Poniżej checklist, którą wypracowałam – żeby następnym razem zejść z 3 godzin na 15 minut.

Krok 1: Sprawdź czy POST W OGÓLE dociera

Zanim zaczniesz sprawdzać nazwy pól – potwierdź że request dochodzi do endpointa. Otwórz w przeglądarce DevTools (F12), zakładka Network, wyślij formularz. Znajdź request idący na domenę marketing automation.

Sprawdź trzy rzeczy:

• Request URL – czy zgadza się z endpointem konfigurowanym w formularzu? Bo jeśli WP Rocket cachuje HTML, atrybut data-endpoint-url na formie może być stary i lecieć na nieistniejący endpoint.
• Request Method – musi być POST. Jeśli GET, JavaScript nie wysłał, tylko przeglądarka zrobiła nawigację po submicie normalnego forma bez preventDefault.
• Status Code – 200 OK znaczy że doszło. 302 Found z redirectem na „Error Location” znaczy że doszło ale system marketing odrzucił. 4xx/5xx znaczy że problem po drodze (zły URL, firewall, cokolwiek).

W moim przypadku: 302 z errorMessage w URL redirectu. Czyli POST dochodzi, system dostaje dane, ale coś je odrzuca.

Krok 2: Sprawdź Payload w Network tab

W tym samym request, zakładka Payload (albo Request) w DevTools. Zobacz konkretnie jakie pola z jakimi wartościami wysyłasz.

Ważne pytania:

• Czy wszystkie pola z formularza są w payload? Może któreś się nie zebrało bo JS mial buga w zbieraniu.
• Czy nazwy pól odpowiadają dokładnie temu, co jest w Field Mapping? Nawet drobna literówka, nawet spacja vs podkreślenie („Nazwa firmy” vs „Nazwa_firmy”) – system marketing nie znajdzie mapowania.
• Czy jakieś pole ma pustą wartość mimo że użytkownik coś wpisał? To by znaczyło że JS coś przemielił.

W moim przypadku: 13 pól, wszystkie z wartościami, wszystkie nazwy zgodne z Field Mapping. Czyli po stronie WordPress wszystko było OK.

Tip do konsoli: jeśli wolisz zamiast klikać po Payload w Network zobaczyć wszystkie pola w tabeli, otwórz konsolę (F12 → Console) i wklej ten one-liner PRZED wysłaniem formularza:

console.table(Object.fromEntries(new FormData(document.querySelector('form'))));

Wyświetli czytelną tabelę z nazwami pól i wartościami. Wygodne gdy trzeba porównać z listą Field Mapping w systemie marketing. To narzędziowy snippet do debugowania na żywo – nie coś co ma zostać w kodzie produkcyjnym.

Krok 3: Sprawdź allFields w odpowiedzi

Jeśli system marketing automation odsyła Cię z errorMessage – w URL redirectu widać też parametr allFields. To lista pól, które system rozpoznał i przetworzył.

Trzy scenariusze:

• allFields zawiera Twoje pola – system je widzi, ale któreś jest niewalidowane. Sprawdź walidacje custom fields w systemie marketing (typ dropdown z listą dozwolonych wartości, regex email, itp.).
• allFields zawiera CZĘŚĆ pól – reszta jest tak nazwana, że system ich nie rozpoznał. Sprawdź jeszcze raz Field Mapping.
• allFields jest PUSTE – system nie rozpoznał ŻADNEGO pola. To rzadka sytuacja i sygnalizuje problem po stronie samego handlera, nie mapping.

Krok 4: Gdy allFields jest puste – sprawdź Completion Actions

Tu utknęłam najdłużej. Puste allFields znaczy, że coś odrzuca cały submit ZANIM system dojdzie do mapowania pól. Jedno z miejsc, gdzie to się może zdarzyć – Completion Actions handlera.

Completion Actions to lista rzeczy, które system marketing ma zrobić po sukcesie: dodać leada do konkretnej kampanii CRM, zmienić custom field na konkretną wartość, powiadomić konkretnego usera, przypisać leada do konkretnego usera.

Jeśli któraś z tych akcji failuje przed właściwym przetworzeniem:

• Kampania CRM jest w statusie „nieaktywna” albo „to be processed” – dodanie leada niemożliwe.
• Custom field ma ustawić wartość, której nie ma na liście dozwolonych (dropdown z ograniczonymi opcjami) – failure.
• User do powiadomienia został usunięty z systemu – failure.
• Warunkowa akcja „if X change Y” ma źle skonfigurowany warunek.

W tym drugim przypadku: klient miał Completion Action „if Source is empty, set Source to Web”. Pole Source w konfiguracji custom fields było skonfigurowane jako dropdown z listą wartości – a „Web” nie było na liście. System próbował ustawić niedozwoloną wartość i rollback’ował cały submit.

Ten sam handler w konfiguracji dwa tygodnie wcześniej (bez tej Completion Action) działał poprawnie. Ktoś w międzyczasie dorzucił nową akcję „poprawiającą jakość danych” – i zepsuł cały pipeline.

Krok 5: Sprawdź Total Submissions w statystykach handlera

System marketing automation ma statystyki per handler. Otwórz konkretny form handler, sprawdź „Total Submissions” – liczba wszystkich prób submitu (nie ważne czy sukces czy fail).

Jeśli jest 0 mimo że wysłałaś testowo 10 razy – system w ogóle nie widzi Twoich requestów. Coś je przechwytuje po drodze (WAF, firewall, DDoS protection na poziomie serwera marketing automation).

Jeśli jest zgodna z Twoimi próbami – requesty dochodzą, problem jest wewnątrz systemu.

Krok 6: Sprawdź Errors log handlera

Systemy marketing automation zwykle mają log błędów per handler. Otwórz – powinny tam być zapisy z konkretnymi błędami dla każdej odrzuconej próby.

Uwaga: jeśli allFields jest puste i Total Submissions też jest 0 – Errors log też będzie pusty. Bo system uważa, że nie dostał niczego do przetworzenia (mimo że fizycznie POST doszedł). To sygnalizuje problem konfiguracyjny na poziomie samego handlera (deaktywacja, whitelist IP, itp.), a nie problem z pojedynczym submitem.

Kiedy odpuścić i zapytać administratora systemu

Jeśli po krokach 1-6 masz:

• POST idzie na właściwy URL
• Payload ma wszystkie pola z prawidłowymi nazwami
• allFields puste
• Total Submissions 0
• Errors log pusty

To NIE JEST Twój problem. To problem administratora systemu marketing automation. Poproś go o:

1. Sprawdzenie statusu handlera (aktywny/nieaktywny)
2. Sprawdzenie wszystkich Completion Actions (czy któraś nie failuje)
3. Sprawdzenie custom fields (czy dropdown values są aktualne)
4. Sprawdzenie kampanii CRM podpiętych pod Completion Action (czy są aktywne)

Wyślij mu dokładny screen: Twój Payload z DevTools + screen odpowiedzi z errorMessage. On w 15 minut znajdzie problem, którego Ty z zewnątrz nie zobaczysz.

Podsumowanie

Klucz do debugowania form handlera marketing automation: nie zakładaj że problem jest tam gdzie widzisz kod, którym się zajmujesz. Formularz na WordPressie może być idealny, a submit i tak będzie failował z powodu konfiguracji po drugiej stronie.

Checklist ratuje 2-3 godziny frustracji. Zamiast szukać buga u siebie przez godziny, przez 15 minut idziesz punkt po punkcie i lokalizujesz gdzie problem naprawdę leży.