Custom Fields

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.

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

1. What decision does this field change? If none, do not add it.
2. Who populates it, and at what moment.
3. Is it a choice or free text?
4. 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.

Showing Fields Conditionally

A custom field that only applies sometimes should only appear sometimes.

Where to find it

Architect Panel → Forms:

• Custom Fields — the custom field definitions
• Conditional Forms — the show and hide rules

Architect Panel → Security:

• Permissions — restricting who may see a value

Why it matters

Fields accumulate, and most of them apply to a minority of records. A form showing all of them asks everybody about circumstances that do not apply to them, and the answer to a question that does not apply is usually wrong rather than blank.

Drive it from a defined choice

The field controlling visibility should be a constrained option, not free text. A rule matching "Yes" fails on "yes", "Y" and a trailing space, and the symptom is a field that appears for some people and not others with no discernible pattern.

Show groups, not individual fields

Where several fields apply in the same circumstance, reveal them together. One rule showing a section is easier to read, easier to change and much easier to test than six rules doing the same thing.

Match required to visible

A field that is required and hidden is a form that cannot be submitted, with nothing on screen explaining why. It presents to the user as a submit button that does nothing, and it is the commonest fault in conditional forms.

A field should be required exactly when it is shown.

Decide what happens to an answer that gets hidden

Somebody answers, changes an earlier answer, and the question disappears. Is the answer kept or cleared? Both behaviours exist; the wrong one either resurrects an answer unexpectedly or silently loses work.

Decide once, and be consistent across your forms.

Hiding is not security

The caution worth repeating. A hidden field is hidden in the interface. It is not protected, and it is still there in exports, in the API and in reports.

If somebody must not see a value, that is field security. Conditional display is about relevance, not access.

Keep the rules few

Three simple rules are comprehensible. Fifteen interacting ones produce behaviour nobody can predict, including whoever wrote them — and the way you find out is a user reporting that a field "sometimes" appears.

Test every combination

Each value of the deciding field, end to end, including changing your mind part way. That last path is where conditional fields go wrong.

Worked example

A case form shows one of three field groups depending on case type, using three rules on a constrained field. Testing the change-your-mind path found a hidden field still blocking submission, which was corrected before release.

Recommendations

• Drive rules from constrained choices.
• Reveal groups rather than individual fields.
• Required exactly when shown.
• Never use hiding as a security control.