Fluent form not submitting: walk the form

A multi-step form checks each page before it lets the visitor move on, and an answer on one page can decide whether another question appears. When the visitor picks an answer that opens an extra question, that question can still count as required even though the visitor never sees it on the screen they are on. Next then looks broken, or Submit does nothing on the last page. A second cause sits in the cache. A stored copy of the form page can carry a security token from an earlier visit, and the server refuses a submit that carries it.

• Fill only the first page and press Next. Note whether the next page opens, and what you see if it does not.
• For each answer that opens a new question, check that the hidden questions are not still marked required.
• Press Submit on the last page with everything empty. Note which page the first error sits on.
• Open the page in a private window with caching off, then submit. If that works, a cached token is the cause.
• After a successful test, check the entries list. An entry that never appears points at the server.

A single-page form fails in one place. A multi-step form fails on the page that is currently open, and the visitor has no way to know which page holds the blocked answer. They sit on page two, press Next, and watch nothing happen. Some builders keep the earlier pages in memory, so going back and forward does not reset anything. The visitor reads that as the form being broken, not as one answer on an earlier page that they have to change.

A condition shows a question when a certain answer is picked, and it should also drop that question's required setting when the answer changes back. Many forms only hide the question. The field stays in the list of things the form checks, so the form refuses to move on while the visitor cannot see the field. Pick each answer that opens a question, then pick the other answer and confirm the form moves on. A path that gets stuck only after one specific answer is often this fault.

WordPress forms carry a security token so the server can confirm a submit came from the form it served. A caching plugin can store the page with that token inside it, and the token can expire while the stored copy keeps being served. The visitor fills the form, presses Submit, and the server rejects a token it no longer recognizes. The rejection can look like a silent failure because the form simply shows the same page again.

A simulated visitor fills the pages in order, follows the answer paths you choose, and records the page where each path stopped. The report gives that page, a screenshot of the form at that moment, and any failed request the browser logged on Submit. The run cannot read your form's conditions or your caching settings, so it cannot name the field or the token at fault.

Multi-step forms grow. Someone adds a question under a new option, changes a condition, or moves a field to a later page, and a path that worked last month now stops on a page nobody reads. After each edit, run every answer path that opens a new page, including the path through the new option, and confirm each one reaches the end.