Naming and checking your App's data

Two things you can say about a field

Your App's lists store fields with short, code-shaped names like signupDate. You can add two things to each one:

• How it reads — what people should call it and how its value should be shown. signupDate becomes "Signup Date", and 2026-02-01T00:00:00.000Z becomes a date.
• What it accepts — a required field, a minimum length, a range, a set of allowed choices, no duplicates.

Both are settings on the field. You do not write code for either, and the AI reads the same settings when it builds against your list.

Where to set them

1. In the App editor, open Develop › Data.
2. Under Lists, press a list's settings icon — or New list to start one.
3. In the Fields table, press a field's settings icon. Its section opens below the table.
4. Select More settings (it reads Fewer settings while open), make your changes, then press Save.

The Fields table holds what most lists ever need: each field's name, its Type (Text, Number, Yes / No, Date or Any), and three switches — Required, Search (the field can be searched on its own) and Link (it points at another list). Type a name in the box under the table and press Enter, or the + beside it (Add a field), to add one; the trash icon removes one, and Cancel undoes anything you haven't saved.

Your existing lists already read sensibly with no edit at all — a field with no label shows a tidied-up version of its own name, and a date already shows as a date — so More settings is for when you want something other than the sensible default.

A list can only be saved while your App's saving is on. With it off, the window says Saving · Off at the top and offers no Save until it is turned on.

While list changes land on Live at once, a collaborator can add fields but can't change a stored field's type, make it required or remove it — those change your visitors' records, so they are the owner's.

How it reads

• Label — what people call the field. Leave it empty and your field's own name is tidied up instead; the window shows you what that will be.
• Description — what the field holds. Shown beside the value.
• Shown as — the format: Text, Long text, Email, Link, Phone, Number, Whole number, Money, Percent, Date, Date and time, Time. Only the formats stored the same way as the field's type are offered. Pick Money and you are asked for a currency.
• Hide the value — a switch, for anything private. The value is masked wherever it is shown, and it is blanked when your Live records are copied into your Draft's data, so real customer details never end up in your working copy.

A list with a hidden field, an Email or Phone field, or records that belong to Each signed-in user holds people's personal details, so its records are never copied to other people when you start a co-op with your App — that co-op can only start empty. Another of your Apps can still be linked to such a list, but only to read it, never to write to it.

What it accepts

Required is the switch in the Fields table. Everything else is under What it accepts in More settings, one line per rule, and the lines offered depend on the kind of field:

• Length (text) — the shortest and longest the value may be.
• Pattern (text) — a pattern the whole value must match. When you set one, also write the plain-English explanation shown when it does not match — the expression itself means nothing to the person filling in the form.
• Range (numbers and dates) — the smallest and the largest value.
• Allowed values (text and numbers) — a list of the values a field may hold, comma separated.
• No duplicates (text, numbers and dates) — a switch, so no two records can hold the same value.

You can also give a field a Starting value — what a new record begins with when nothing is supplied.

Where the rules are enforced

Everywhere something is saved:

• Your published App's own forms check before submitting, so the person is told what is wrong straight away.
• The server checks every save regardless, so a rule still holds if someone bypasses your form.
• Your own edits in a record's window, and any file you import, are held to the same rules. An import that breaks a rule is refused whole rather than half-loaded.

The message is the same sentence in every case — "Signup Date is required" — so a rule never sounds like two different rules depending on where you hit it.

Two things behave the way you would want but are worth stating. A field's format is never used to reject anything; it changes how a value is shown and which keyboard the form offers, so a field that reads as an email will not start refusing your existing records. And No duplicates is the one rule only the server can check, since it has to look at your other records.

Renaming a field keeps its values

Change a field's name in the list's Fields table and press Save. The editor recognises that as a rename rather than a delete-and-add, so every record's value moves to the new name — your data comes with it and nothing is dropped.

There is one rule worth knowing: if a record already holds a value under the new name, that record keeps it. A rename fills in the records that have nothing under the new name and leaves the rest exactly as they are, so it can never overwrite something you already had.

Records are rewritten where they sit rather than copied out and back, so links between your lists keep pointing at the same records, and a record's own history is unaffected.

A list's own name can't be changed: the name is how its records, its links and your App's code find it, so a new name makes a new list.

Link a field to another list

Turn on a field's Link switch when it holds the ID of a record in another list — an order's customer, a post's author. A Link section opens below the table:

• To list — the list it points at. Pick one, or choose Another list… and type a name; a list that doesn't exist yet is marked not made yet.
• Match — the field on that list to match against. Leave it empty to match the record's ID.
• Holds — one record, or many.

The list's card on Lists shows each link. A link never changes how your records are stored: it tells your App's code, and the AI writing it, how to join the two lists when reading them.

Reading your data

In Develop › Data → Records, columns show the labels and cells show the formatted values, so the table reads the way your App does.

Press a record's pencil to open its window, which shows every field both ways at once — one row per field with its Field label, its Type, the name it is Stored as, its Value as stored (which you can edit), how it Reads as, and what it Accepts. You are building this App, so you need to know exactly what your code and the AI will receive. Stored at the foot shows the whole record exactly as saved, and the window says which dataset — Live or Draft — it came from. A hidden field is masked here too, with a Show control when you want to see it.