Form Validation

Type: How-to | Audience: End-user | Goal: Understand validation rules

Required Fields

1. Select an input field inside your form.
2. Toggle Required on in the input settings.
3. When enabled, the form cannot be submitted until the user fills in this field.

Hidden inputs ignore Required

The Required toggle is forced off when the input type is Hidden — there is no way to require a hidden field.

Required from data

Use data when some records need the field and others do not.

1. Click the ⇄ button beside the Required label. A Data Picker field replaces the switch.
2. Bind the field to a value, for example must_fill.
3. The field is required when the value is true, yes or 1. Case and surrounding spaces do not matter.

Any other value leaves the field optional. This includes an empty value, no, 0, false and a value that does not resolve, so an empty Data Picker field shows no warning. The value comes from the view data (Sample data, Received data, variables, System context). It does not read other inputs in the same form.

Click ⇄ again to go back to the switch. The switch keeps its earlier position, and the Data Picker value is kept too.

Disabled has the same choice and follows the same rule. A disabled field sends its Default Value when the form is submitted, and its validation (Required, Pattern, bounds) does not run.

Pattern Validation

Use regex patterns to enforce custom input formats:

1. Select a text-based input field (Text, Textarea, Email, Number, URL, or Date type).
2. Enter a regex expression in the Pattern field (e.g., ^\d{3}-\d{4}$ for a phone format like 123-4567). The field accepts a literal regex, or a Data Picker placeholder (e.g. validation_rules.email_pattern) that resolves to one at submit time.
3. Once Pattern has a value, a Pattern Error field appears underneath. Set it to override the default error message shown when the input does not match. Pattern Error also supports the Data Picker, so the message can be localised or context-dependent.

If no custom error message is set, a default validation error is shown.

When the value a user submits is itself a Data Picker placeholder (e.g. a prefilled field bound to a template variable), the regex check is skipped -- the resolved value is trusted to be validated by the backend.

Number Min/Max Validation

For Number type inputs, bound the accepted range:

1. Select a Number input field.
2. Set Min and/or Max to the desired bounds. Both accept either a literal number or a Data Picker placeholder that resolves to one (e.g. min_age).
3. Once Min has a value, a Min Error field appears; once Max has a value, a Max Error field appears. Use these to customise the messages shown when the submitted value falls outside the bounds.

Bounds are enforced at submit. If the value is below Min or above Max, the form does not submit and the error message appears next to the field. Changing the input Type away from Number clears all four fields (Min, Max, Min Error, Max Error) automatically.

Built-in Type Validation

Certain input types have automatic validation:

• Email -- validates email address format.
• URL -- validates URL format.
• Number -- only accepts numeric input.

No extra configuration is needed -- these validate automatically on form submission.

File Type Limits

Set Accepted file types on a File input to take only some kinds of file. Write one comma-separated list of extensions and MIME types:

.pdf, .docx, image/*

• A bare word such as pdf reads as .pdf. Case does not matter, and extra commas are ignored.
• An entry that is neither an extension nor a MIME type, such as *.pdf or image/, shows an error under the field.
• An empty list accepts every file.

The file dialog offers only the listed types. The drop zone hint starts with the list, such as .pdf, .png, image/* · One file · max 10 MB; after three types it shows +N more. While a user drags a file of another type over the drop zone, the zone turns red and reads File type not accepted (.pdf, .png). During a drag the browser shows only the file's MIME type, so the warning needs a MIME type for every entry: it never comes while the list holds an extension whose MIME type the field does not know.

A file of another type can still arrive, for example by a drop. It joins the selection, its row turns red, and the form does not submit until the user removes it. The message names the file and the list:

File "setup.exe" is not an accepted type (.pdf, .png)

This is a check in the browser only. The server does not read the list, so do not rely on it to keep a file type out of your endpoint.

File Size Limits

A file input is guarded in two places -- your own limits in the browser, and the server's budget -- and they fail with different messages.

1. Your own limits, in the browser

You set up to three limits on the field. Each one has its own message, so the user is told which limit they passed and by how much. The form does not submit until the selection clears all three.

Max File Size (MB) applies to each file on its own, never to the selection added up -- three 5 MB files pass a 10 MB limit. An oversized file also turns its own row in the field red as soon as it is picked, and the message names the file:

File "contract.pdf" is 12.4 MB, which exceeds the 10 MB limit

Max Total Size (MB) applies to the selection added up. Only a field with Allow multiple files on has it:

The selected files total 12.4 MB, which exceeds the 10 MB limit

Max Number of Files caps how many files the field takes. It too belongs to a multi-file field alone, and it is the only limit that stops a user attaching hundreds of tiny files:

14 files selected, which exceeds the limit of 10 files

The range you may set for the two size limits depends on the surrounding form's Form Type: JSON forms allow up to 10 MB, Multipart/Form-Data forms allow up to 100 MB. The count may go up to 25 on JSON forms and 50 on Multipart/Form-Data, and arrives pre-filled with 10. The label inside Block Settings shows the active ceiling for each, and the size fields arrive pre-filled with it -- lower a number yourself if you want a tighter check.

When a selection breaks more than one limit at once, the user reads the file type message first, then the per-file size message, then the count, then the total size. A file of the wrong type must go whatever its size, and the two per-file messages are the ones that name a file, so they say what to drop.

2. The submission budget, on the server

Setting your own limits low enough does not guarantee the submission goes through. The server never sees them; it weighs every file field of the submission together against one budget of its own, so files that each passed check 1 can still be refused as a group. The user gets an error toast naming both numbers, and the form is never sent:

The submission carries 12.6 MB of files, more than the 10 MB this form accepts. Send fewer or smaller files.

To stay clear of it, keep the whole form's uploads under the budget for its Form Type, and move a form that needs more than 10 MB onto Multipart/Form-Data. The numbers, the reason they differ, and the one case that fails without this message are in File Size Limits.

No file inputs in "Open view with form data"

A form whose Form Type is Open view with form data cannot contain a file input -- the builder shows a clear validation error if you try.

Builder Validation Warnings

The builder itself validates form structure and shows Action required cards directly on the canvas inside an empty form:

• Missing input field -- with an Add input quick-fix button. Add an input block between the Form Start and Form End rows.
• Missing submit button -- with an Add submit button quick-fix button. Add a button anywhere in the view, set Button Type to Form Submit Button, and select this form in the Form dropdown.

Each card includes a one-click action button that drops the missing block in the right place.

Other validation rules block save until they are resolved -- see Saving for the full list (duplicate input names, submit/reset buttons that point at a non-existent form, file inputs in Open view with form data forms, missing URLs).

Unique Input Names

Each input has a Name field (the first row in Block Settings) that becomes the field key when the form is submitted. The builder generates an initial name like Input and appends a numeric suffix on duplicates -- a second input becomes Input_2, a third becomes Input_3, and so on.

You can rename inputs from the Name field whenever you want to make the submitted JSON more readable.

Input names must be unique

If two inputs end up sharing a name (typically by manual editing), the builder flags an Input name must be unique validation error and blocks save until you change one.