Fields: built-in and your own

A field is one piece of information that every entry in a collection carries: a candidate's email, a listing's asking price, a proposal's due date. Every collection has two kinds of field: a small built-in set that all collections share and you cannot edit, and the fields you add yourself.

Requirements

To read this page: none. To add, change, or archive fields: a role that can edit the collection's structure.

What a field is

If a collection is a sheet and an entry is a row, a field is a column (elsewhere: attribute, property). It gives every entry in the collection the same slot for the same kind of fact, and it decides what that slot accepts.

Take a staffing firm. Its Candidates collection has fields for the candidate's name, emails, phone numbers, the role they are placed in, the recruiter who owns them, and the date they became available. Each entry fills in the same fields, so the team can filter, sort, and report on them, and an agent reads them the same way a person does.

Built-in fields

Every collection starts with the same seven fields. You do not add them and you cannot edit them:

• Name: the entry's title. Required, at least three characters.
• Slug: the entry's address-friendly identifier, created from the name if you do not set one.
• Status: draft, published, or unpublished. Required. New entries start as drafts in collections you create; the collections that come with a new business start them as published.
• Published Start Date and Published End Date: the window in which the entry counts as published.
• Published Timezone: the timezone those two dates are read in.
• Location: which location, and which departments inside it, the entry belongs to.

Status and the publishing dates matter most when a collection is connected to a website: they decide which entries the site can show. Status and publishing explains the states and the window; the site side is covered in How collections power a site.

Your fields: what a type decides

Everything else is a field you add. Each one has a type, and the type decides what the field accepts and how it behaves. Types fall into a few families:

• Text: single-line and multi-line text, rich text, links.
• Numbers and money: numbers, prices, currency amounts.
• Choices: an option field with a fixed list of values, single or multiple.
• Dates: date and time.
• Contact details: emails, phone numbers, addresses, each available as a single value or as a group.
• Media: images, image galleries, files, video links.
• Connections to other entries: a reference to one entry, a multi-reference to several, and variants that can point into more than one collection. See How references connect entries.
• People: a field that holds users of the business.
• Computed: rollup and lookup, described below.

A type is chosen once. After the field is created, its type and its slug stay fixed. To change a type, you archive the field and create a new one; Add or change a field walks through it.

Rules a field can carry

Beyond its type, a field you add can carry a label, help text shown to whoever fills it in, and four switches:

• Required: a published entry cannot be saved without a value. A draft can be saved with it still empty, so an entry can be finished later.
• Unique: no two entries in the collection can hold the same value; archived entries do not count.
• Searchable: the value is included when people and agents search the collection, and the field can be filtered on and shown as a column in a view.
• Read-only: the value can be set when the entry is created, and later edits to it are refused. Automations still write to it, which is what makes it useful for values the system manages, such as the moment an order was dispatched.

A field can also depend on others through field rules, which limit, fill in, clear, or lock it under conditions.

A people field can also be marked as the one that says who runs an entry. Record-level visibility reads that field when it decides who sees which entries, and an entry you create is assigned to you by default.

Fields the system fills in

Two types are never written by anyone: rollup and lookup. The system computes their values and recalculates them when related entries change. A rollup counts or sums values across related entries, such as the number of placements a recruiter has made; a lookup shows one value from a referenced entry, such as the client's industry on a placement. Rollup vs lookup covers when to use each.

Secret fields

Some values should be stored but never exposed: an API key for a client's system, an access code. A text field can be declared secret, and there is a separate password type for the strictest case.

• A secret value is encrypted before it is stored.
• Members of the business see it; the public website, exports, and AI and integration views never do.
• A password field goes further: its value is never shown back to anyone once saved.

Notes and limitations

• A field's type and slug cannot be changed after it is created.
• Built-in fields cannot be edited.
• A secret field cannot be unique or searchable, and it cannot be turned back into an ordinary field once saved. Moving the data out is a migration, not a setting.
• Fields installed by a blueprint can be protected. You can still change their label and help text, but you cannot archive them.
• Archiving a field is reversible, and it is blocked while field rules still depend on that field.

Related

Start with Collections and entries for the model this page builds on, then Add or change a field for the steps. For which kind of connection to use between collections, see Reference vs multi-reference. For the limits on image and file fields, see Formats and limits for assets.