Forms
A form collects something from a visitor: an enquiry, a service request, a subscription, an application.
Back office → Structure → Forms.
Building one
Add fields the way you add them to a content type. Each field has a label, a kind, whether it is required, and help text.
The kinds:
| Kind | What the visitor gets | What is stored |
|---|---|---|
| Text | one line | the text |
| Long text | a paragraph box | the text |
| one line, must be a valid address | the address | |
| Number | one line, must be a number | the number |
| Checkbox | one yes/no tick | true or false |
| Select | a drop-down, one of the options | the chosen option |
| Checkboxes | the options as ticks, any number of them | the list of ticked options |
Select and Checkboxes need their options — one per line in the back office, comma-separated where a field asks for them. A required Checkboxes field needs at least one tick.
A form declares what happens on submit: store the submission, send a mail, create a record, or several of those together. An enquiry that becomes a lead in the CRM is a form with a record action.
Submissions
Everything submitted is stored, per organization, and can be listed, filtered and exported like any other data.
A form is personal data
Almost every public form collects something identifying. It falls under the platform's GDPR machinery — export, erasure and retention apply to submissions like everything else. Set a retention period when you build the form, not after somebody asks.
Security
Public forms post rather than get. That is not a preference:
Never a GET form for anything private
A form submitted by GET puts every value in the address — where it lands in browser history, in server logs, and in the referrer sent to the next site. A password or an email address in a URL has already leaked before anyone reads the page.
Submissions are rate-limited and validated on the server. Client-side validation is a courtesy to the visitor, never a control.
Spam
Forms carry the usual protections. If a form starts collecting rubbish, raise the limits before adding a puzzle for legitimate visitors to solve.
On the website
Every enabled form has a public page at /form/<machine name>/ on the
firm's website, drawn by the website itself — the same header, menu,
footer and language as every other page. A form bound to a firm appears
on that firm's site only; a form without a firm appears on every site.
A form can also sit inside a page: place a Form block (Structure → Block layout) in a region, choose the form and whether its fields take one or two columns. The block draws the same form the page does — an enquiry can live in the middle of the front page, next to the text that asks for it. Link the page from a menu or a text like any other address.
The page shows the fields in the order you built them, marks the required ones, and on success shows the form's confirmation text. Wrong input is named per field, in the visitor's language; nothing is stored until every field passes. The bot trap works exactly as before: a hidden field a person never sees, and a minimum time between opening the page and sending it.
Why the website draws it
Until 238 the form page was rendered by the platform's own public shell,
outside the website's design — a visitor landed on a page with a different
header, menu and footer and read it as a broken foreign site. The page now
comes through the website's form door (/api/web/v1/forms/<machine name>):
the definition out, the values in, validation and the trap unchanged on
the server. Nothing about the form itself moved; only who draws it.