Skip to content

Forms

6 min read · By Stefan Köhn

A form is the public front of an entity. Every field in it writes into a field of that entity, and what a visitor submits becomes a record. You build in three columns: the supply on the left, the form in the middle, the properties of whatever is selected on the right.

A form belongs to one entity

It does not ask for anything at all, it asks for the fields of one particular entity. So before the first form there is always an entity with its fields. The entity never changes afterwards: swapping it would mean losing every field in the form. The gain shows later. What comes in is sorted, filterable and reportable from the start, instead of being a collection of free text somebody has to file by hand.

Intake or amendment, decided when you create it

An intake form creates a new record on every submission. That is the normal case, the contact form on a website. An amendment form changes an existing record and accepts nothing at all without the link from an email; how that works is under Asking for something later. The purpose is fixed after creation because half the builder hangs off it: which actions exist, whether required fields are asked for, whether the form shows anything at all.

Two lists, two meanings

At the top left, a search filters all lists by name, followed by blocks such as Pick a time. Then come the fields the entity already has; taking one of those reuses it. Below are new field types; taking one of those creates a new field on the entity when you save. The difference is the most important one in the whole builder, because the second permanently changes the entity, for every other form and every report too. Until you save, such a field is only a draft: leaving the builder without saving leaves no half fields behind.

What belongs to the form, what to the entity

The form owns the label, placeholder, help text, the share of the row, whether a field is hidden and how a choice looks. That is how visitors are addressed and how the page is laid out. Required, format and choices say something about the data and belong to the entity. You still change them in the builder, in the Field tab: required and format under On the entity, the values under Choices. They are saved with the form. They then apply wherever the field appears, in every other form and in the record; the tab tells you how many forms that is. The field type and key are still changed on the entity itself, because they rebuild stored values.

The form decides how a choice looks

The same choice appears as a dropdown, radio buttons, checkboxes or cards. You set this in the Field tab under Choices, and the canvas shows it right away. With cards, every value has a slot for its image in front of it, and visitors click the image instead of a line in a list. Display and images belong to the form: two forms on the same field may look different, one with images on your website and one without at a partner. The record always stores the value, never the image. Values without an image show their label. An image is uploaded only when you save, so a discarded draft leaves nothing behind.

Rows divide by share

A field spans the full width. Drag a second one onto it and both share the row; a third makes thirds, a fifth makes fifths. There is no column grid anything has to fit into, and no half empty row. For uneven widths, set the share on the field: street with 3 and number with 1 give three quarters and one quarter. On a phone every row falls into a single column, because five fields side by side would be unusable there.

Conditions point backwards

A field and a whole page can appear depending on an earlier answer. Only fields that come before it are offered. A page whose visibility depends on an answer given on itself would have no definite state. That is why the first page never carries a condition: a form that starts with an unmet condition shows the visitor nothing. The server evaluates the same conditions again when something arrives. A value behind a condition that is not met is not written, even if somebody sends it by hand.

Step by step

  1. Open Forms in the menu on the left and click Form in the top right.
  2. Enter a name and pick the purpose. Intake creates a new record on every submission, Amendment changes an existing one.
  3. Drag fields from the left column onto the page. The entity's fields are at the top, the types for a new field below them.
  4. Click a field and set its label, help text and share of the row on the right.
  5. Save. Only then do the new fields appear on the entity.
  6. Switch it live in the top right and copy the snippet under Embed onto your own page.

What is the difference between the two lists on the left?

The top one holds fields the entity already has; they get reused. Below are new field types; those create a new field on the entity when you save.

Why does the label appear twice?

The entity knows the field name, the form knows the label visitors see. If they differ, that is shown underneath, with a button to reset it.

Why is a field suddenly required in another form too?

Required, format and choices belong to the entity, even when you change them in the builder. They therefore apply in every form with that field. The Field tab shows how many forms that is, above the settings.

What does the notice about missing required fields mean?

The entity marks fields as required that this form does not ask for. A form with that gap cannot be switched live, because the records from it would arrive incomplete.

Can I change a form's entity later?

No. Every field in the form points at a field of that entity; a change would leave none of them standing. If you need the other entity, create a second form.

Is a record still created if I switch all actions off?

Yes. The record is always created, the actions only decide what happens on top. A form without a record would be data nobody finds.

Where do I see how a form is doing?

The list shows views, submissions and completion rate for the last thirty days. Clicking them opens the analytics with a period and a funnel.

Do I lose my work if I leave the builder?

An unsaved draft lives in the browser only, which is why leaving asks first. New fields also appear on the entity only when you save.