Custom fields and values

How a project stops being a set of text boxes and starts being structured.

Custom fields

A field you add to a record type, which then exists on every record of that type in the project. A character gains an allegiance; a location gains a population; an entry gains a category.

Fields are per project, so two projects in the same account can have entirely different shapes.

Field types

Text, number, date, and a value from a list. The list type is the interesting one.

Custom values

A vocabulary you define once and reuse: the five houses, the four schools of magic, the ranks in the navy. A field of list type draws from one.

This is worth doing as soon as you have typed the same word into three records. Once a field draws from a list:

• It cannot be misspelled, so filtering actually works.
• Renaming the value renames it everywhere.
• The list is a record of what exists, which is useful in itself — the five houses are five houses because the list says so.

Filtering

Fields backed by values are filterable in list views: every character of the third house, every location with a population above ten thousand. Free-text fields are searchable but not filterable, which is the practical argument for using a list wherever you can.

Changing your mind

A field can be removed, and doing so removes it from every record — the data goes with it. Renaming is safe. Changing a field's type is not always possible, because a date is not a number; the product will tell you when it cannot.