Forms & the form designer

The form designer builds the input side of your app: create and edit records, run guided actions, collect structured data. Like pages, forms are pure configuration — fields, rules and behavior — and everything sensitive (validation, submit logic, permissions) runs on the server.

Form types

Type	What it's for
Table-backed form	Bound to one of your tables — submitting creates or updates a record directly, with the platform enforcing the caller's permissions
Action form	Not tied to a table — submitting runs a trusted server function you define (multi-table writes, calling other services, custom workflows)

Either type can be presented as a full page, opened in a modal from a button or row action, or embedded inside a page you built in the UI designer.

Designing a form

Forms → New form, pick the app (and the table, for table-backed forms).
Add fields and arrange them — fields sit on a 12-column grid, so two half-width fields share a row naturally.
Configure each field inline: label, placeholder, required, default value, and the advanced behaviors below.
Choose what submit does and how success is confirmed.

Field types at a glance

Text & numbers — single line, multi-line, numeric with ranges.
Choices — dropdown selects, radio groups and card selectors (rich clickable options with icons and descriptions).
References — pick a record from another table, shown by its display field with search built in.
Dates & times — date, time and combined pickers.
Toggles — booleans as switches or checkboxes.
Files & images — uploads stored securely in your instance; image fields offer crop and resize before upload.
Advanced — JSON and code fields for technical apps.

The complete list with every option lives in the UI builder reference.

Advanced capabilities

Visibility rules — show or hide any field based on other fields' values, evaluated live as the user types ("show PO number only when Tier is Enterprise").
Dynamic choices — a select's options can be computed on the server at open time: from your data, filtered per user, or from an external source.
Server-side validation — requiredness and format checks run in the browser for speed, and again on the server for trust.
Custom submit logic — a server function receives the values and decides what happens: write records, call other functions, then tell the UI what to do next (show a success message, refresh, navigate).
Permission awareness — a user who isn't allowed to write to the target table sees a disabled submit with an explanation, and the server refuses the write regardless of what a client sends.

Example: a "New contact" form

Name and Email side by side (half-width each), both required.
Account — a reference field that searches your accounts table.
Tier — a card selector: Free, Pro, Enterprise, each with an icon.
PO number — appears only when Tier is Enterprise.
Submit — creates the contact, notifies the account owner via a server function, shows "Contact created" and refreshes the underlying table.

Field-by-field configuration keys, the form definition format and the submit-handler API are documented in the UI builder reference.