Screen Builder
The screens your team works in are derived from the model — forms for changing data, lists for finding it — then shaped without code. Every field keys to a model attribute; every list column binds to one.
From model to form
A form binds to an entity. Its fields key to the entity's attributes — pick the attribute, and the field knows its type, its constraints, and its place in the model. Attributes you leave out simply aren't on the form; nothing breaks, and nothing has to be kept in sync by hand.
Required is a live state in the working form, not a note in a spec. Constraint notes travel with the field from the builder to the screen your team sees. Layout is a grid you shape directly — sections, rows, and columns, resized in place.
What the relation kinds become
On the Model Builder page, relations carry a kind. This is where the kind pays off. A parent relation renders as a reference picker on the child's form — searchable, filtered, with add-new in place. A child relation with tabs renders as a tab on the parent's form, embedding that entity's live list. A child relation with master-detail renders as inline rows on the parent form itself — added, edited, and removed without leaving the screen.
You choose the kind once, in the model. The forms follow.
Choose the kind in the model →Build a form
The same builder our engineers use — layout, grid, and a preview of the working form.
From model to list
Lists are how your team finds and moves through records. Columns bind to model attributes; reference columns render as links that carry the reader to the record's form. Date formats, sorting, grouping, and typed filters are configuration, not code — and the filter panel sits where you put it.
Build a list
Columns, behavior, and a preview of the working list.
Every field, every column
Required, validated live
Required fields validate in the working form as your team types — not after submit.
Reference components
Searchable pickers with filters, two-step search, and add-new in place — the related record created without leaving the form.
Constraint notes
Guidance written once in the builder appears with the field everywhere the form is used.
Custom components
When the built-ins aren't enough: your own markup, logic, and styles, bound to model data.
Screens become the portal
Forms and lists become dashboards, assembled into menus by role — the portal your team logs into is made of the screens you just saw built.