Marketing automation Form Handler returns “field required” but everything is filled – debug checklist

When data sends but the marketing automation system “doesn’t see it”

Situation from one project: WordPress form sends 13 fields to a marketing automation endpoint. All have values. All have names matching the Field Mapping in the marketing system. And the system, after every submit, returns:

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

The key is where you won’t look at first glance: allFields is empty. There’s no list of fields the system recognized. No list of fields it rejected. Nothing. As if no field reached the handler – and yet the POST goes through with 200 OK.

A few hours of debugging later it turned out the problem wasn’t in the WordPress form. It was in the marketing automation configuration on the client’s side. Below is the checklist I worked out – so next time we’d drop from 3 hours to 15 minutes.

Step 1: Check if POST reaches the endpoint AT ALL

Before you start checking field names – confirm the request reaches the endpoint. Open browser DevTools (F12), Network tab, submit the form. Find the request going to the marketing automation domain.

Check three things:

• Request URL – does it match the endpoint configured on the form? Because if WP Rocket caches HTML, the data-endpoint-url attribute on the form may be stale and going to a non-existent endpoint.
• Request Method – has to be POST. If GET, the JavaScript didn’t send it, the browser just navigated after a normal form submit without preventDefault.
• Status Code – 200 OK means it arrived. 302 Found with a redirect to “Error Location” means it arrived but the marketing system rejected it. 4xx/5xx means a problem on the way (wrong URL, firewall, whatever).

In my case: 302 with errorMessage in the redirect URL. So the POST reaches, the system gets data, but something rejects it.

Step 2: Check Payload in Network tab

In the same request, Payload (or Request) tab in DevTools. See specifically which fields with which values you’re sending.

Important questions:

• Are all form fields in the payload? Maybe one didn’t get collected because JS had a bug in collecting.
• Do field names match EXACTLY what’s in Field Mapping? Even a small typo, even a space vs underscore (“Company Name” vs “Company_Name”) – the marketing system won’t find the mapping.
• Does any field have an empty value even though the user entered something? That would mean JS mangled something.

In my case: 13 fields, all with values, all names matching Field Mapping. So on the WordPress side everything was OK.

Console tip: if you’d rather see all fields in a table instead of clicking through Payload in Network, open the console (F12 → Console) and paste this one-liner BEFORE submitting the form:

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

It renders a clean table with field names and values. Handy when you need to compare with the Field Mapping list in the marketing system. This is a debugging snippet for live diagnostics – not something meant to stay in production code.

Step 3: Check allFields in the response

If the marketing automation system sends you back with errorMessage – in the redirect URL you also see the allFields parameter. This is the list of fields the system recognized and processed.

Three scenarios:

• allFields contains your fields – the system sees them, but one is failing validation. Check custom fields validations in the marketing system (dropdown type with allowed values, email regex, etc.).
• allFields contains PART of the fields – the rest are named such that the system didn’t recognize them. Check Field Mapping again.
• allFields is EMPTY – the system didn’t recognize ANY field. This is a rare situation and signals a problem on the handler itself, not the mapping.

Step 4: When allFields is empty – check Completion Actions

This is where I got stuck the longest. Empty allFields means something rejects the whole submit BEFORE the system gets to field mapping. One of the places this can happen – Completion Actions of the handler.

Completion Actions are a list of things the marketing system should do after success: add a lead to a specific CRM campaign, change a custom field to a specific value, notify a specific user, assign a lead to a specific user.

If any of these actions fails before proper processing:

• The CRM campaign is in “inactive” or “to be processed” status – adding a lead impossible.
• A custom field is supposed to set a value that’s not on the allowed list (dropdown with limited options) – failure.
• The user to notify has been removed from the system – failure.
• The conditional action “if X change Y” has a misconfigured condition.

In this second case: the client had a Completion Action “if Source is empty, set Source to Web”. The Source field in the custom fields config was set up as a dropdown with a value list – and “Web” wasn’t on the list. The system tried to set a disallowed value and rolled back the whole submit.

The same handler two weeks earlier (without this Completion Action) worked correctly. Someone in the meantime added a new “data quality improving” action – and broke the whole pipeline.

Step 5: Check Total Submissions in handler stats

The marketing automation system has per-handler stats. Open a specific form handler, check “Total Submissions” – the number of all submit attempts (whether success or fail).

If it’s 0 despite you testing 10 times – the system doesn’t see your requests at all. Something is intercepting them on the way (WAF, firewall, DDoS protection at the marketing automation server level).

If it matches your attempts – requests reach, the problem is inside the system.

Step 6: Check the handler’s Errors log

Marketing automation systems usually have an error log per handler. Open it – there should be entries with specific errors for each rejected attempt.

Note: if allFields is empty and Total Submissions is 0 – Errors log will also be empty. Because the system considers it didn’t get anything to process (even though the POST physically arrived). This signals a configuration problem at the handler level itself (deactivation, IP whitelist, etc.), not a problem with a single submit.

When to give up and ask the system administrator

If after steps 1-6 you have:

• POST goes to the right URL
• Payload has all fields with correct names
• allFields empty
• Total Submissions 0
• Errors log empty

This is NOT your problem. This is the marketing automation system administrator’s problem. Ask them to:

1. Check the handler status (active/inactive)
2. Check all Completion Actions (whether any fails)
3. Check custom fields (whether dropdown values are current)
4. Check CRM campaigns linked to Completion Action (whether they’re active)

Send them the exact screen: your Payload from DevTools + screen of the response with errorMessage. They’ll find in 15 minutes a problem you won’t see from the outside.

Summary

Key to debugging a marketing automation form handler: don’t assume the problem is where you see the code you’re working with. The WordPress form can be perfect, and the submit will still fail because of the configuration on the other side.

Checklist saves 2-3 hours of frustration. Instead of looking for a bug in your own code for hours, in 15 minutes you go point by point and locate where the problem actually lies.