Forms and records

The form is the record, rendered

In most systems a form is drawn, and the record it writes into is defined somewhere else. Two descriptions of the same thing, kept in step by whoever remembers to.

Here there is one description. A record type declares its fields - what they are, what they mean, what is required - and the form is that, rendered. Add a field to the process and it is on the form; make it conditional and the form respects it; change its type and every screen showing it changes together.

So a form never falls behind the process it belongs to, and nobody has to build one before a new request type can be filed.

And when you want it arranged, you arrange it

Generated does not mean take-it-or-leave-it. The layout is editable: the order fields appear in, how they are grouped, which of them belong on the first screen and which are detail, what is shown to whom.

The distinction that matters: you are arranging a description, not drawing a picture. The arrangement is part of the record type, so it holds wherever the form opens - in an app, on a portal, in a task board - instead of being a property of one screen somebody laid out once.

What a field can be

The palette is the one a business form actually needs, not the four types a generic builder offers.

Text and numbers - short text, long text, number, currency, percent, a rating
Dates - date, date and time, and the automatic ones: created, last modified, and by whom
Choices - a single or multiple selection from a fixed set, with its own colours
Contact details - email, phone, link
Files - attachments, so a photo of the damage, a scan of the invoice or a signed document arrives with the request instead of in a follow-up email
Codes - a barcode field, an autonumber that assigns itself
References to real things - an employee, a department, a position, a legal entity from the org structure; a product, a warehouse or a counterparty from master data; a row from a dataset; a linked record in another list; a task in another process
Derived values - a formula field, and a lookup that shows a field from the other side of a link without copying it

That reference group is what separates a form from a questionnaire. A field holding an employee is not a name somebody typed - it is that person, which is why the route can send the request to them.

Rules that hold before the record is saved

Required, so what the next person needs is there, not promised.
Validation rules on the value, picked from a list instead of coded: a minimum or maximum number, a shortest or longest text, digits only, whole numbers only, letters only, a pattern to match, a maximum file size, which file types are allowed. Each with your own message, so the person filling the form is told what is wrong in your words, not in ours.
A rule of your own where the list stops - a condition written in the same {{Field name}} notation as everything else: {{Price}} > 0, or a date that must not precede another field's. Checked when the record is edited, not discovered downstream.
Read-only where a value is not the author's to set - a status that belongs to the process, a lookup that belongs to the linked record, a computed total.
Cascading choices. A picker can depend on the field beside it: choose the department and the positions narrow to that department. The dependency is declared once with the record type, so it behaves the same on every screen the form opens on.

Calculations in the form

A field can compute instead of being filled in: a total from a quantity and a price, days between two dates, a score from three answers, a flag that turns on above a threshold.

One notation, everywhere. A formula refers to a field by the label a human reads, in double braces - {{Quantity}} * {{Price}} - and it is the same notation in a form, in a spreadsheet and in an exploration table. Learn it once and it reads the same in all three; a formula written in one place is recognisable in the next.

And mostly you do not write it. A builder lists what is available - the fields of the record and the functions, each with a line saying what it does - and inserts them, so the formula is assembled by choosing instead of by remembering names and getting a bracket wrong.

Formulas are evaluated in a sandbox with an execution limit, and the result is typed like any other field - so a computed value can be filtered on, reported on and used in a condition on a transition, not merely displayed.

One set of records, three ways to work them

The same records, seen the way the work needs them:

The form - one record at a time, for filing and for deciding.
The list - many at once, sortable and filterable, for scanning and for bulk work.
The board - a kanban grouped by status. Drag a card into the next column and the work moves; because that move is an ordinary transition, whatever the process attaches to it still applies - the condition, the approval, the automation. Cards carry checklists you tick off and add to without opening the record, and a checklist item can be discussed on its own. A filter bar narrows the board to what you are looking at today.

These are views, not copies. A field edited on a card is edited in the record; a filter on the list does not need a second definition of what the record is.

Everything that happens is recorded

Every record carries its own history: what changed, from what to what, when, and by whom.

And it opens from the record. The history is part of the record, so whoever can see the record can see how it got that way without asking an administrator or querying an audit log. That turns "who moved this to approved, and when" from an investigation into a glance.

And discussion sits on the record

A record is not only fields. The platform's collaboration works here exactly as it does on a dataset, a project or a range of cells in a spreadsheet:

Comment threads on the record, so the question about a request sits on that request.
@-mentions that reach the person through their own channel - Slack, Telegram or email - with an inbox of what is waiting for them, instead of depending on them opening the right screen.
Reactions - a thumbs-up is a decision recorded in a second, and it saves three messages of people agreeing in prose.
Quoting and replying, so a long thread stays followable.
Attachments on the discussion as well as on the record.
Edit history on the comments themselves, and resolve-and-reopen when a thread is finished and when it turns out not to be.

So the argument about a request lives on the request, instead of in a chat somebody has to be invited to. The same mechanism, everywhere it attaches: what collaboration can do.

The form opens where the work is

A form is a component, and it goes where it is needed:

In an application - as a page, so filing a request is part of the app people already use.
On a portal page - as a block among the others, next to the figures or the news it relates to. See Portals and pages.
On a task board - open the card and the form is there, with the transitions available from this status.
From a list or a directory - expand a row and edit the record in place.
Beside a spreadsheet - a row expands into the same field components, so a grid and a form are two ways of looking at the same record, not two implementations. See Spreadsheets.

One record type, one set of rules, one history - and as many places to work with it as the work requires.

Automation - what happens after the form is submitted, without anybody doing it.