Skip to main content
A form is a layout over a Record Set. The Record Set decides what data exists and what is valid; the form decides how it is asked for — which fields appear, in what order, in what columns, with which controls, and under what conditions. The two are deliberately separate. One Record Set can carry several forms, so a supplier onboarding set can have a short “Add a supplier” form for the operations team and a longer “Full supplier review” form for procurement, both writing to the same records.

​
How a form relates to its Record Set

The schema owns validity

Field names, types, required-ness, allowed values, minimums and patterns. Enforced on every save, by the browser and again by the service.

The form owns presentation

Which fields are placed, their layout, their labels and placeholders, which control renders them, and the conditional logic that shows or hides them.
A form places fields — it does not create them. A field must exist in the schema before it can be placed, and a field left out of a form is still part of the record; it is simply not asked for on that form.
Because presentation lives on the placed field rather than on the schema, the same field can be a plain text box on one form and a dropdown with a curated list of choices on another. Changing a label on one form never touches the other.

​
What a form carries

A Record Set always keeps at least one form — the delete control is disabled on the last one. Where nothing has picked a particular form, the one named Default is used, falling back to the first form in the list.

​
Several forms, and which one a Space uses

When a Record Set offers more than one form, each Space picks the one it uses at Edit Space → Records → Form views, which lists every attached Record Set with a dropdown of its forms. A Record Set with a single form has nothing to choose.
Pinning a form is per Space, not per person. Everyone working in that Space gets the same form for that Record Set. If two groups genuinely need different questions, that is two Spaces or two Record Sets — not two forms in one Space.

​
Where a form is actually filled in

There is no single “forms” area. A form surfaces in three places, all of which write to the same records.
Open a Space, go to Records, pick a Record Set on the left. New record opens the Space’s pinned form as a create form; clicking an existing row opens the record, and Edit reopens the same form with the stored values loaded.
A task can carry a Fill in form action pointing at a Record Set — and, where the set offers several forms, at a named one. The assignee completes it from the task rather than from the record table. Several forms on one action become several steps, completed in order and resumable. See Task Actions.
A form can be raised as a card in a chat, either whole or cut into sections that Abbie asks about a few at a time. See Form flows.
There is no public form link. A QuivaWorks form cannot be published to an anonymous URL the way a survey tool publishes one. Everyone who fills a form in is signed in — a colleague in the Space, or a client signed into the client portal. If you need to collect something from someone with no account at all, that is a job for an inbound channel, not a form link.

​
What the person filling it in sees

The form renders as the rows you laid out, in order, with the columns you chose. It collapses to a single column on a narrow screen.
1

Fields appear and disappear as they answer

A field or a row carrying a conditional rule shows only while its condition holds. Nothing is greyed out or crossed through — it is simply not there. See Form rules.
2

Validation runs on submit, not on every keystroke

Pressing the submit control checks the whole form at once and marks each failing field with its own message underneath it.
3

Hidden answers are discarded

Anything hidden by a rule at the moment of submission is stripped out before validation and before saving. A value typed under an earlier answer, then hidden when that answer changed, does not survive onto the record.
4

The record is checked again on the way in

The service validates every record against the Record Set’s schema on create and on update. A record that fails is rejected outright — nothing is coerced and nothing is partly saved.

​
The two validation passes

A submit runs two checks and merges the results. Where both have something to say about one field, the schema’s message is the more specific one and is the one shown.
Required has two homes, and they behave differently. Marking a field required in the schema makes it required everywhere, on every form and on every API write. Marking a placed field required in the form’s inspector makes it required on that form only. A short intake form can leave a field optional while a fuller review form insists on it — as long as the schema itself does not demand it.

​
A word of warning about “rules”

Forms have conditional logic, and so do flows — and the two are completely different engines with completely different syntax. A form’s rules are JsonLogic; a flow’s Rules step is a facts-and-rules engine documented separately at Rules. Nothing you learn about one applies to the other. See QuivaWorks has two rule engines.

​
Next

Building a form

The editor: palette, canvas, inspector, and generating a layout from a description.

Fields and elements

Every control available, what each one stores, and the headings, notes and cards around them.

Form rules

Conditional visibility, conditional requirement and computed values.

Form flows

Cutting one form into sections Abbie asks about a few at a time.