Create a collection by naming it for what one entry represents, then adding the fields that describe it. You can create it with its fields in one pass or create it bare and add fields as you go. Housekeeping fields — name, identifier, publication state — are added automatically.

Requirements: a role that can create collections in this business.

Before you start

Decide what a single entry represents, and name the collection for it in the plural — Work Orders, Properties, Enrollments. If you are unsure how to frame that, collections and entries covers it. If a well-trodden setup already covers your need, check whether a blueprint ships it before building by hand.

Steps

Create the collection. Give it a name. An identifier is generated from that name for use in URLs; it is fixed once created, so name the collection properly now rather than renaming later.
Add its fields. For each piece of information an entry carries, add a field and set its type — text, number, date, a fixed set of options, and so on. Choose the type that matches the data: a field's type cannot be changed after it is created. The full detail is in add or change a field.
Set each field's role. Mark a field required if an entry is meaningless without it, unique if no two entries may share the value, and searchable if you will want to filter or show it as a column in a view — only searchable fields are available there.
Connect it to other collections. Where an entry belongs to something else — a work order to its customer — add a reference field pointing at that collection. To link entries within the same collection, use a parent field instead; a reference cannot point at its own collection.
Add derived fields if useful. Once a reference exists, a rollup or lookup can total related entries or borrow a value from the one they point at. These are computed — leave them read-only.
Create one entry to check it. Fill in a real record. If something is awkward to enter, or you find yourself typing the same value repeatedly, fix the model now — a missing field or a reference that should exist.

Two ways to build

You can define the collection with its fields in a single pass, or create it bare and add fields one at a time as the need becomes clear. The first is faster when you already know the shape; the second suits modelling something you are still working out. Neither locks you in — fields can be added at any point.

What you do not need to create

Every collection automatically gets the housekeeping it needs: a display name, a URL-safe identifier, and a publication state that decides whether an entry is publicly visible. Do not add your own fields for these.

Notes and limitations

A field's type is immutable. Changing it means adding a new field and moving the data across, so decide types deliberately.
A field's identifier is also fixed once created — its label can be renamed, its identifier cannot.
References must point at a different collection. Self-referencing relationships use a parent field.
Derived fields are read-only — they cannot be written to, including by import.
Archive rather than delete if you might want a field back — and note that archiving is blocked while a rule depends on it.

The reasoning behind these choices is in working with collections and fields; a guided walkthrough is in build your first collection. For changing a collection after it exists, see add or change a field.

Create a collection