What Custom Fields Are
A custom field extends a datastore with something your organisation needs and the platform did not ship.
Where to find it
Architect Panel → Forms:
- Custom Fields — the custom field definitions
Architect Panel → Data:
- Datastores — the datastore being extended
What a definition carries
More than a name and a type. Each holds:
- Name and friendly name — the internal identifier and what people see.
- Description — help shown to whoever fills it in.
- Type and any additional information the type needs.
- Special feature, where the field behaves as something particular.
- Display width and edit width, separately.
- Default value and validation.
- Required, and its order.
- Encrypt, for values held encrypted at rest.
Display and edit widths are separate
Deliberately, and it is the setting people miss. A field can be narrow in a list and generous on a form, which is almost always what you want — a note column that is readable in a grid and comfortable to type into.
Write the description
It is the cheapest quality control available. A field with a sentence explaining what belongs in it gets filled in correctly; one with only a label gets filled in with whatever the person guessed.
Encrypt anything sensitive
The flag exists so a value is held encrypted rather than in plain text. Anything that would matter in a database backup — a reference to something confidential, a personal detail beyond the ordinary — should carry it.
Set it when the field is created. Retrofitting encryption to a populated field is a migration.
Validate at entry
A wrong value caught at the field is a correction; the same value caught in a report six months later is an investigation. Validation is worth the two minutes on any field with a knowable shape.
Every field is data you hold
Which means it needs a reason, protection, and eventually disposal. Fields are trivial to add and nobody ever removes one, so a datastore accumulates until the form is unusable and half of it is empty.
Before adding one, ask what decision it changes.
Constrained types beat free text
A field you will ever filter, group or report on should be a defined choice. Free text cannot be counted, and "the same thing spelled four ways" is the outcome of every optional text field.
Worked example
A case datastore gained four custom fields: a constrained source, a reference number with validation, a narrow priority shown in lists, and a wide internal note. A review a year later found a fifth field that was empty on ninety per cent of records, which was removed.
Recommendations
- Set display and edit widths separately.
- Write a description on every field.
- Encrypt at creation, not retrospectively.
- Constrained choices for anything you will report on.