Managing Fields

Once fields exist, the Custom Fields screen is where they are looked after: edited, retired, audited, measured and exported. This page covers each of those, and the two read-only reference screens that answer "what types exist" and "what record types can I attach to".

The row menu

Every field in the list has a row menu with eight actions. Each needs its own permission, so a role may see some and not others.

Editing a definition

Editing opens the same form as creating, with the permanent settings shown but not editable: record type, key, value type and scope. Everything else can be changed, and the changes take effect on the next form somebody opens.

If the detail behind the Edit button fails to load, the form deliberately does not open, and you get a message instead. That is a safeguard rather than an inconvenience: the list row does not carry the options, the placeholders or the validator, so opening a form populated from it and saving would silently erase all three.

Visibility rules administration

Visibility rules allow fields to be shown or hidden dynamically on record forms based on the values of sibling custom fields on the same record type. When a rule is active, client-side forms and server-side validation evaluate the conditions deterministically.

A field with several rules is visible only when every one of them is satisfied — a plain AND across all of them, not a contest between competing Show and Hide actions, because a rule only ever expresses one condition to be visible under. Priority orders the rules for diagnostics and display only; it never changes which rules apply. A field a rule is currently hiding is skipped by Required validation too, so a condition nobody can see never blocks a save.

Value-type conversion and rollback

Converting a field's declared value type is a separate operation, reached from its own row-menu action rather than the edit form — it changes how already-stored answers are represented, not just what future ones look like. Only nine specific type pairs are allowed; every other pair is refused outright, including any pair touching a reference type, File, Image or RichText.

Before changing anything, the server checks every stored value against the target type in a first pass that writes nothing. If even one value would fail to convert, the whole operation is refused up front, naming every failing row, and nothing is changed — it is all-or-nothing, never a partial conversion that leaves some rows old and some new.

Field definition versions and drafts lifecycle

A definition's live scalars, options and visibility rules can be cloned into an isolated draft, then either published — replacing the live version in one step — or discarded, leaving the live version untouched either way.

Publishing a draft deprecates the incumbent Published version in the same save. The version number always increments, and every form load from that point serves the new Published version.

Retiring a field: deactivate or delete

These are not the same operation and the difference matters. If you are unsure, deactivate — it is the reversible one.

• ✅

  Turning Active off

  • The field stops being offered on create and edit forms
  • Every answer already stored is kept, untouched
  • It is reversible — turning Active back on restores the field as it was
  • It is recorded in history as Deactivated, and can be Reactivated later
• ⚠️

  Deleting the definition

  • Refused on the first attempt if the field holds any answers
  • Destroys those answers once the retention window passes, if you confirm
  • Frees the key, so a new field could later reuse it — with none of the old answers
  • Is recorded in history as Deleted, and may be Restored while it is recoverable

Definition history

The History entry in a field's row menu opens a dialog listing what has happened to that field's definition, newest first, with the person who did it and when. A change made by the system rather than a person is attributed to the system. Entries are paged, and the dialog says how many changes there are in total.

Each entry also says which part of the field it concerns, because a field is more than a single row.

Usage and impact

The Usage & impact entry in the row menu reports what the field is actually carrying before you change or remove it. Read the whole dialog rather than one number.

Deleting without destroying data

Deleting a field that holds answers takes two deliberate steps. A field with no answers takes one.

1. 1

   Open Usage & impact first

   See how many answers exist and where they are. If the number surprises you, stop here — deactivating the field is almost always the better move.
2. 2

   Choose Delete

   If the field holds answers, the delete is refused with a conflict and the dialog explains exactly what would be lost, naming the number of stored values and the number of record types.
3. 3

   Confirm the destructive delete

   Confirming from inside that dialog is what actually proceeds. This is a separate, explicit act rather than a second click on the same button, so a field with data cannot be removed by momentum.
4. 4

   Or delete an empty field in one step

   A field with no answers deletes with no warning and no extra step, because there is nothing to lose.

A confirmed delete destroys the stored answers once the retention window passes, not instantly. Until then the definition may still be Restored, and history records both the delete and the restore. After the window, the answers are gone and the history entry reads as Purged.

Exporting definitions to a spreadsheet

The Export action in the Custom Fields page header downloads a spreadsheet of the definitions you can see, one row per field with headers on the first row. These are the 18 columns.

Yes/no columns are written as the words Yes and No rather than as spreadsheet booleans, so they survive being opened in a different language and still read as intended.

The two reference screens

Both are reached from links in the Custom Fields page header, both are read-only, and both are gated behind the same view permission as the Custom Fields screen itself. Neither has a sidebar entry of its own, which is deliberate.

Value Types

A table of all twenty-two value types with, for each, a description of what it is for, whether it takes a placeholder, whether it owns an options list, and whether it supports a validator. Use it to answer "what types exist" without opening a definition form. Text is the only row showing validator support, and the four reference-shaped types (EntityReference, UserReference, File, Image) show no options list of their own — what they point at comes from another module or an upload rather than from a list you author.

Entity Types

A list of every record type a custom field can be attached to: its display name, its key, and the module that owns it.

It also shows two separate screen columns plus a status, which is not a duplication. One is what the platform claims about this application; the other is what this application actually has. The status column says whether the two agree, and a row reading Out of Sync is a real defect worth reporting — it means either a field pointed at a record type nobody can render, or a screen the platform does not know exists.