n8n builds forms two different ways depending on where the form sits in a workflow: the Form Trigger node starts a workflow when someone submits a standalone form, and the plain Form node adds an additional page mid-workflow so a single form can span several steps with logic running between them. Both render a hosted page at a URL n8n generates, both collect typed fields, text, email, number, dropdown, checkboxes, file upload, hidden fields, and both hand the submitted data to the rest of the workflow as normal JSON. The difference is entry point versus checkpoint, and mixing them up is the most common reason a multi-step form does not match what actually happens when the fields save.
This walks through building a genuine multi-step form: a Form Trigger as the entry point, one or more Form node pages after it for later steps, basic validation on required fields, and a look at where the submitted data actually goes once the workflow finishes running. It also covers the two URLs every form gets, the attribution toggle worth knowing about, and what production readiness means for a workflow triggered by a public form.
Table of contents
- Form Trigger vs Form node: pick the right one first
- Setting up the entry point with Form Trigger
- Adding a second page with the Form node for multi-step forms
- Field types and validation that actually stops bad input
- Test URL, Production URL, and the attribution toggle
- Where the data goes after the form closes
- How this fits the rest of the stack
- FAQ
Form Trigger vs Form node: pick the right one first
n8n gives you two ways to put a form in front of someone, and they solve different problems even though both render as a webpage with fields and a submit button. The Form Trigger node is a trigger: it sits at the very start of a workflow and the workflow only runs once someone submits it, the same way a webhook trigger fires a workflow on an incoming request. The Form node is not a trigger at all; it is a regular node placed later in an already-running workflow, and it pauses execution to show the next page of a form before continuing.
The rule of thumb that avoids most of the confusion: use Form Trigger once, at the start, to begin the workflow. Use Form node as many times as needed after it, one call per page, to build out the remaining steps of a genuinely multi-step form where later questions can depend on what happened with earlier ones.
Setting up the entry point with Form Trigger
Start a new workflow and add a Form Trigger as the first node. n8n generates a Form Path automatically, a UUID by default, and it can be replaced with a readable path in the node’s Form Path field so the final URL looks like a project name rather than a random string. Add fields under Form Elements: a Field Label for what the visitor sees, a Field Name for how the value shows up in the node’s output, an Element Type, and a Required Field toggle. Text, Email, Number, Dropdown, Checkboxes, Date, File, and Password are all available from the same list.
{
"formTitle": "Project intake",
"formFields": [
{ "fieldLabel": "Full name", "fieldType": "text", "requiredField": true },
{ "fieldLabel": "Work email", "fieldType": "email", "requiredField": true },
{ "fieldLabel": "Company size", "fieldType": "dropdown", "fieldOptions": ["1-10", "11-50", "51+"] }
]
}Save the workflow and n8n shows the Form Trigger node’s Test URL and Production URL at the top of the node panel. Opening the Test URL while the workflow is in editing mode renders the page exactly as a visitor would see it, the fastest way to check field order and labels before wiring up anything downstream.
Adding a second page with the Form node for multi-step forms
For a second step, add a Form node anywhere later in the workflow, after whatever logic needs to run between pages, an IF node branching on an earlier answer, for instance. The Form node’s own field configuration works identically to the Form Trigger’s: the same Field Label, Field Name, Element Type, and Required Field options, so a page added mid-workflow looks and behaves consistently with the entry page.
Execution pauses at the Form node until the visitor submits that page, then resumes with the new fields merged into the workflow’s data alongside whatever the Form Trigger collected first. That merge is what makes a multi-step form actually multi-step rather than three disconnected forms: by the final page, every node downstream can see every answer from every earlier page, exactly what conditional logic across steps needs.
A last Form node can set a custom completion message instead of a fixed thank-you page, worth using for anything where the next step genuinely differs depending on what was submitted.
Field types and validation that actually stops bad input
Validation on a form that talks straight to a workflow matters more than on a typical marketing form, because bad input reaches whatever the workflow does with it, not just a database row nobody looks at. n8n’s own field options cover the basics directly:
- Required Field stops a submission with an empty field from completing at all.
- Element Type enforces shape at the browser level: Email expects an email pattern, Number restricts to numeric input, Dropdown and Radio Buttons remove free text entirely.
- Placeholder and Default value guide the visitor toward the expected format without hard-enforcing it.
For validation past that, the honest answer is that the Form node does not have a general regex or custom-rule field, so the pattern most workflows use is an IF node immediately after the trigger that checks the submitted value and routes anything malformed to an error branch, whether that ends the workflow quietly or sends a message back asking for a correction. Treat the native field types as the first pass and the IF node as the real gate.
Test URL, Production URL, and the attribution toggle
Every form-producing node carries two URLs. The Test URL only works while the workflow is open in the editor and every execution against it shows up as a manual test run; it is meant for you, not for a form you have shared. The Production URL only works once the workflow is activated, and only then does it trigger runs that count as live executions.
One option worth deciding early is Append n8n Attribution, on by default, which prints a small Form automated with n8n line at the bottom of the page. Turning it off is a one-toggle change in Node options and matters for anything customer-facing where a visible third-party attribution reads oddly next to your own branding.
Where the data goes after the form closes
The workflow’s job does not end at rendering the confirmation page; where the data goes after that is the entire point of routing it through n8n instead of a plain HTML form. The most common next step is an HTTP Request node sending the submission to another API, a CRM or a notification service, and n8n’s own workflow templates library has a working example of most of those destinations to start from rather than building the request from scratch.
For anything you will need to query, filter, or report on later, sending the submission to a chat channel is not enough; it needs a row in a database. A Postgres node writing each submission into a table, with the Form Trigger’s fields mapped straight to columns, turns a form into a small, queryable record of everything submitted, instead of a stream of notifications nobody can search afterward. That pairing, a form-triggered workflow next to a database it actually writes to, is also the shape covered by installing and getting n8n running in the first place.
It is worth remembering that n8n itself is the workflow engine, not the storage layer; whichever database sits behind the Postgres node is a separate piece that needs its own backups and connection limits, the same as any other application talking to a database.
How this fits the rest of the stack
A form that only sends a notification is a webhook with extra steps; a form that writes to a database is the start of an actual record you can query later. Running that pairing yourself means keeping n8n patched, backed up, and reachable, exactly the maintenance a managed instance removes: n8n deploys on its own plan with a live URL, environment variables, and logs through the dashboard, with a managed Postgres database sitting right beside it for the rows the form produces. The RunxBuild hosting calculator prices both together rather than as a guess.
Useful related references:
- n8n vs Make: Where the Complexity Goes
- n8n Use Cases: What It Is Genuinely Good At, and What It Is Not
- n8n Alternatives: The Honest Comparison by What You Are Escaping
- Node services on RunxBuild
FAQ
What is the difference between the n8n Form Trigger and Form node?
Form Trigger is a trigger node that starts a workflow when someone submits it, always the first node in the workflow. The Form node is a regular node placed later in an already-running workflow, and it pauses execution to show another form page before continuing, which is how multi-step forms are built.
Can n8n forms have multiple steps?
Yes. A Form Trigger starts the workflow with the first page, and one or more Form nodes placed later add additional pages, with logic like an IF node able to run between pages. By the final page, every node downstream can see the answers from every earlier page.
Where do n8n form submissions go?
Nowhere by default beyond the workflow’s own execution. The submitted fields are available to every node after the trigger as normal data, so where they go depends on what you add: a notification node for an alert, an HTTP Request node to call another API, or a database node to write the submission to a table for later querying.
What is the difference between the n8n Form Trigger’s Test URL and Production URL?
The Test URL only works while the workflow is open in the editor and only produces manual test executions. The Production URL only starts accepting real submissions once the workflow is activated, at which point those executions count as live runs.
Does n8n support form field validation?
Partially, natively. The Required Field toggle and the Element Type itself, Email or Number for instance, enforce basic shape at the form level. Anything beyond that, a custom pattern or a business rule, needs an IF node after the trigger checking the submitted value and routing invalid submissions to an error branch.