Add or change a field

Requirements: a role that can edit the collection's fields.

Adding a field

1. Name it for what it holds, in the words your team uses.
2. Choose the type. This is the decision that matters: text, number, date, a fixed set of options, a link to another collection, an image. Pick what matches the data — a price is a number, a date is a date — because the type cannot be changed afterwards.
3. Set its role. Required if an entry is meaningless without it. Unique if no two entries may share the value. Searchable if you will want to filter or column on it in a view — easy to forget and the usual reason a field is missing when building one.
4. Configure what the type needs. An option field needs its list of options. A link to another collection needs to know which collection. A computed field needs to know what it is summarizing or borrowing.
5. Check it on a real entry — open one and confirm the field accepts what you expect.

Changing a field later

Editing a field is the same action as adding one — you are simply updating what is already there. Most things are safely adjustable after the fact:

• Freely changeable: the label, whether it is required, unique, or searchable, and the options in an option list.
• Fixed for good: the type, and the field's underlying identifier. The label can be renamed, but the identifier stays as first created.

If you truly need a different type, add a new field of the right type, move the data across, then archive the old one. There is no in-place conversion, which is exactly why the type is worth a moment's thought when you create it.

Retiring a field

Prefer archiving over deleting: archiving retires the field without discarding what it held, so a mistake is recoverable. One thing to know — if a conditional rule on the collection depends on that field, archiving is blocked until you remove or repoint the rule. That is a safeguard: silently removing a field that another field's behavior depends on would leave the collection inconsistent.

Notes and limitations

• Type is immutable after creation. Changing type means a new field plus a data move.
• The identifier is fixed even though the label can be renamed — the two may differ later, which is fine.
• Adding required to a field with existing entries means those entries are now incomplete — fill them before enforcing it.
• Adding unique to a field that already has duplicates will not hold — clean the duplicates first.
• Removing an option from an option list leaves entries that used it stranded — repoint them before removing the value.
• Computed fields cannot be written to, before or after editing — see rollup vs lookup.
• Archiving is blocked while a field rule references the field.

Related

Creating the collection itself is in create a collection; the reasoning behind field choices in working with collections and fields. For linking fields, see reference vs multi-reference; for whether something should be a field at all, stages vs option field vs status.