Custom fields without building a second product

Custom fields are where a well-modelled register slowly turns back into a spreadsheet. Not because they are wrong, but because the wrong placement of a field is invisible on the day it is added and expensive a year later.

The placement test

Before adding a field, ask what it would do if the thing it is attached to were replaced. That single question resolves most cases:

• It stays with the machine forever — asset. Serial number, year of manufacture, supply voltage.
• It is replaced when the paperwork is renewed — obligation. Certificate number, issuing body, scope of accreditation.
• It describes the commitment rather than any one instance — plan. Interval, tolerance, procedure reference.
• It was true at one moment — evidence. Ambient temperature, reading, engineer, batch affected.

The classic error is putting the certificate number on the asset. It works, right up to the first renewal — at which point either you overwrite it and lose the history, or you add a second field called Previous certificate number and the slide has begun.

The field that is really a relationship

Watch for fields whose values are a list of other things in the register: an owner typed as text, a parent machine written as a name, a location that is really a site. These are relationships written down as strings, and they are the fields that later block every report you want.

The tell is that you find yourself wanting to filter on it and discovering three spellings. If a field's values should be a set, make it a set — a reference to a real row, not free text.

Fewer fields, filled in honestly

There is a hard trade-off here that no amount of interface design resolves. Every required field is a small tax on the person at the machine with cold hands and a clipboard, and a field that is tedious and not obviously useful gets filled with whatever passes validation.

A field that is always filled in with the same value is not data. It is a question your form is asking nobody.

Review the field set periodically and look for exactly that: fields with one distinct value across hundreds of records. Either the field is not needed, or it is needed and the form is not getting a truthful answer. Both are worth knowing, and both are usually fixed by deleting it.

Why this is configuration, not code

All of this only works if adding a field is an insert rather than a migration and a deploy. When custom fields are rows, a sector's peculiarities live in its data; when they are columns, they live in your schema, and supporting the next industry becomes a fork of the product.

That is the same reason obligation kinds are rows rather than an enum. An enum is a migration every time a customer has a kind you did not think of, and there is always a kind you did not think of.