Adding a Field

Adding a field is quick. Adding one well takes a few more minutes and saves a great deal.

Where to find it

Architect Panel → Forms:

Custom Fields — the custom field definitions

Architect Panel → Data:

Datastores — the datastore and its layout

Decide before you add

What decision does this field change? If none, do not add it.
Who populates it, and at what moment.
Is it a choice or free text?
Is it required, and what happens to the records that already exist.

The fourth is the one that causes trouble. Marking a new field required makes every existing record incomplete, and the first person to open one cannot save it without answering a question about work they did last year.

Add it optional first

Then populate the back catalogue, then make it required. That sequence avoids blocking people on data nobody has.

Choose the type for the data, not the form

A date is a date, not text that looks like one. A number is a number. Fields typed loosely because it was quicker to enter are fields that cannot be sorted, compared or totalled, and re-typing a populated field is a migration.

Set a default that is true

A default is what most records will hold, and it should be the value you would want if nobody thought about it. A default that is merely the first option produces data that is confidently wrong.

Where there is no sensible default, leave it empty — an empty field is honest.

Place it in the layout

A new field appears at the end unless you put it somewhere. The end of a long form is where nobody looks, so adding a field is also the moment to revisit the layout.

Tell the people who use it

A field that appears without explanation gets ignored or filled in wrongly. One sentence to the team, when it appears, is the difference between a field that works and one that produces noise for six months.

Check the downstream

Views, exports, imports, templates and integrations. A new field does not break them, but a new required field breaks anything that creates a record without it — an import, an integration, a form.

Then look at it a month later

How often is it populated, and with what? A field that is empty on most records is either badly explained or not needed, and both are worth knowing.

Worked example

A source field was added optional, populated across existing records from an export, and only then made required — after checking that the two integrations creating cases could supply it. A month later its values showed one option accounting for four fifths of records, which prompted a better set of choices.

Recommendations

Optional first, populate, then require.
Type for the data, not for the form.
Place it in the layout rather than leaving it at the end.
Check what creates records before making a field required.