Field name rules (Pro)
Every question in a form has a field name - the key it is sent under in the webhook payload. A system receiving those payloads keys on that name, so the same question has to arrive under the same name from every form. One form calling it email and the next emailadres is a broken integration, and nothing in the builder normally says so.
LocalForm → Settings → Webhooks → Field names is where you write that contract down. A rule pins one concept to one field name, and the form builder checks it live while an admin types.
What a rule looks like
A rule names the field once, then says how to recognize a question that means it:
| Setting | What it does |
|---|---|
| Field name | The one name this concept is always sent under - email, company, order_reference. |
| Describes | A human label for the rule, shown in the builder's notice. |
| Applies to question types | Every question of a checked type has to use this name (every E-mail question is named email). |
| Or its label contains | Comma-separated words, case insensitive. This is how a rule covers your own questions: a label reading "Bedrijfsnaam" can be pinned to company. |
| Names that are always wrong | Comma-separated names you know are mistakes. These are flagged even on a form that already has a correctly named question. |
| Every form must include this field | The builder shows a notice above the form while the question is missing. |
| When broken | Warn, Block save, or Rename in webhook - see below. |
A rule stays quiet about a second question of a type it targets once the form already names the concept correctly: a form with email plus a "repeat your e-mail" question is fine, while a stray emailadres on that same form is still flagged, because a name listed as wrong is wrong either way.
What happens when a form disagrees
| When broken | Effect |
|---|---|
| Warn | The builder points it out, inline on the question and in a notice above the form. The form still saves. |
| Block save | The form cannot be saved until the question is renamed. The builder refuses the save, and so does the server, so this holds even for a save that never ran the builder's script. |
| Rename in webhook | The form is left exactly as it is, and the field is sent to the webhook under the rule's name anyway. |
Rename in webhook is the option for a form that is already collecting submissions. Renaming its question would split the answers it already has across two keys; renaming only the outgoing payload leaves the stored submissions, the export and the admin screens untouched while the receiver still gets the one name it expects.
A rename is skipped when the payload already carries the target name - two questions cannot share one key, and dropping either answer would be worse than sending the original name.
In the builder
While a form is open, the rules are checked as you type. A question with the wrong name gets a hint under its field name with a Rename to … button, and a notice above the form lists everything at once. A question missing from the form entirely is called out at the top of that notice, with a button that adds it, correctly named and typed.
A rule set to Rename in webhook shows up there too, as a plain statement of what the receiver gets - nothing to fix.
Which forms are checked
By default, only forms that actually send somewhere: a form with its own webhook URL, or any form when the site has a default webhook URL under Settings → Webhooks → Configuration. A plain contact form that saves submissions and sends nothing has no contract to break.
Turn Only check forms that send to a webhook off to hold every form on the site to the rules.
Forms written by the assistant
The AI assistant, MCP tools and the REST abilities write forms without going through the builder. A Block save rule is applied there rather than reported: the field is renamed to its canonical name as the form is written, on the reasoning that an assistant that produced the right question under the wrong name meant the right one. Warn rules leave those writes alone.
For developers
Three hooks, documented in docs/hooks.md:
localform_pro_field_name_rules- declare the rules in code instead of in the admin screen, so the naming contract travels with a deploy.localform_pro_field_name_problems- fires whenever a save breaks a rule, whether or not it was allowed through.localform_pro_field_names_renamed- fires when field names were rewritten in an outgoing payload.