---
title: Plan your fields before you add them
url: https://tideswell.xyz/docs/objects/plan-your-fields-first
description: Sketch an Object's fields before you build it, because a field's type and label are fixed once you save it.
---

> Documentation index: fetch https://tideswell.xyz/llms.txt to discover every page before exploring further.

# Plan your fields before you add them



A **field** is one box of information on a record, and every field belongs to an
**Object**: a kind of record your team defines, built by an admin in **Settings ›
Objects**. If that is new, read <Ref to="objects" /> first.

This page is the four minute sketch worth doing before you open the builder. Almost
everything you set up can be changed later, but a small number of choices are fixed once
the field is saved, and those are the ones people get wrong in the first ten minutes.

## Which decisions are fixed once you save? [#which-decisions-are-fixed-once-you-save]

Three: a field's **label**, its **type**, and, for a linked field, **which Object it points
at**. Once the field is saved, those are set. Correcting one means archiving the field and
adding a replacement alongside it, which leaves the old values where they are.

Everything else you can change whenever you like: the order of your fields, which field
titles every record, the choices in an options list, the stages, and the permission dials.
That is why the field type is worth two minutes of thought rather than twenty seconds.

## What should I write down first? [#what-should-i-write-down-first]

Work backwards from the questions you want to answer, not forwards from the data you
happen to have. Take repairs at Fairgreen Golf Co.

The questions are "how many repairs are open right now", "which supplier sends us the
most", and "how long do they take". That tells you the record needs a stage, a link to the
supplier, and a date.

It also tells you that the customer's phone number, which nobody will ever group by, can be
a plain text field and does not need thinking about at all.

Write down, for each thing you want on the record:

* What it is called, in the words your team already uses
* Whether it is one value or many
* Whether you will ever want to **filter or group** by it
* Whether it points at something else in Tideswell

Those last two are what decide the type.

## Which type do I actually need? [#which-type-do-i-actually-need]

The trap is picking Text because it accepts anything. It does, and six months later you want
to narrow the list by it. Work through these five before you settle on Text:

* If it is one of a fixed set of answers, use **Options list**. "Warranty, Paid, Goodwill"
  as an options list can be filtered and grouped, where the same three words typed into a
  text box are just words. Setting one up is
  <Ref to="objects/choice-lists-and-reference-numbers" />.
* If it points at a supplier, a customer or another record you already keep, use **Linked
  record**. Typing the supplier's name gives you a value that will be spelled three ways by
  March. See <Ref to="objects/link-objects" />.
* If Tideswell can work the value out from other fields, such as a total or a turnaround
  time, let it: see <Ref to="objects/calculated-fields" />.
* If it is money, use **Money**, and read the note that appears when you pick it. Each edit
  sets the amount to whatever is typed, so it suits a figure you restate, such as the cost
  of a repair.
* If it is a date you will sort or count by, use **Date**.

Filtering a record list works on Text, Money, Date, Options list and Linked record fields,
so anything you expect to narrow a list by is best as one of those five.
<Ref to="objects/add-a-field" /> walks all seventeen types and what each one is for.

## Should I tick Required? [#should-i-tick-required]

We recommend ticking it only if a record genuinely makes no sense without the value, and if you are confident
about that now. Required has to hold for every record already saved, so the honest moment to
decide is before any records exist.

Leave it clear for anything a person might reasonably not know at the moment they create the
record. A repair might not have a resolution date on day one.

## How many fields should I start with? [#how-many-fields-should-i-start-with]

Fewer than you think, and in the order you want them read. The first six fields become the
columns on the record list, and everyone who opens that list sees the same six, so those six
are a real decision about what the list is for rather than just a starting order. You can
reorder them later: see <Ref to="objects/rename-reorder-retire" />.

Add the fields you are certain about, use the Object for a week, then add the rest once you
know what is missing. Fields are easy to add. They are not easy to unpick.

## Before you go on [#before-you-go-on]

Once you have your sketch, create the Object first and add the fields to it second. Take it
in that order: <Ref to="objects/create-an-object" /> is the build itself, then add each
field and choose its type. Both steps need an admin, and
<Ref to="concepts/who-can-do-what" /> explains how a person's role turns into what they can
see and change.
