Custom Fields

Custom fields let you add your own information to the records you already work with — a nationality on a person, a preferred foot on a player, a purchase-order number on a booking — without waiting for a release and without anybody writing code. You define the field once on the Custom Fields screen, and from that moment every create and edit form for that kind of record shows it, the record list gains a column for it, and the value you type is stored against that specific record.

What you get

Custom fields are not a free-text notes box bolted onto the side of a record. Each one is a real, typed, named field with its own validation rules, its own place in the form, its own column in the list, and its own audit trail.

• Defined once, used everywhere

  Add the field on the Custom Fields screen and every create and edit form for that record type picks it up, along with an extra column in the record list. No release, no code, no waiting.

• Checked on the way in

  Each value type has its own rules — a real email address, a hex colour, a rating from 1 to 5 — so a wrong value is refused with a specific message rather than quietly stored and discovered six months later.

• Twenty-two value types

  Text and long text, formatted rich text, single and multiple choice, numbers, percentages, ratings, money, durations, dates, date-and-time with a real time zone, times, email, web addresses, phone numbers, yes/no and colour — plus a file and an image, and two that store no text at all and point at a record in another part of the product instead.

• Yours, or the whole platform's

  A field you create belongs to your workspace only. Platform administrators can create global fields that every workspace inherits and no workspace can edit or delete.

• Restrictable field by field

  A role or a user group can hide a specific field from the people holding it, and the product will not let somebody who cannot see a value erase it by editing the record around it.

• Accountable

  Every definition change is recorded with who and when, a usage report tells you how many answers a field holds before you delete it, and the whole set of definitions exports to a spreadsheet.

What a field is made of

This is the complete set of things a field definition carries. Three of them are permanent once saved, because answers already recorded against them would stop making sense if they moved. Control names are shown as they appear in the English interface.

A worked example, start to finish

Suppose the academy needs to record each player's nationality, and the product has no such field. Nothing here needs a developer.

1. 1

   Decide what you are asking

   The question is "what nationality is this player?". The answer is a short piece of text with no fixed list of choices, so the value type is Text. If you did want a fixed list, Select would be the right choice instead — and that decision is permanent, so it is worth a moment's thought.
2. 2

   Define the field

   On the Custom Fields screen, choose Add. Pick the record type for people, set the key to nationality, the English label to Nationality, the value type to Text, and leave Required off for now. Save.
3. 3

   Fill it in

   Open any player record. A Custom Fields section now shows a Nationality input, empty. Type a value and save the record. No error means the value was accepted and stored against that player.
4. 4

   Read it back

   Reopen the record and the value is there. The record list also has a Nationality column now, so you can see the answer for every player at once without opening any of them.
5. 5

   Tighten it up

   Later you decide the field must always be filled in. Edit the definition and turn Required on. From then on a player cannot be saved with Nationality blank — but note that players saved earlier with it blank stay as they are until somebody edits them.

Your workspace, or the whole platform

A field created by an administrator inside a workspace belongs to that workspace. Nobody in another workspace sees it, and its answers are never visible outside it. This is the normal case and needs no thought.

A platform administrator working with no workspace selected creates a global field instead, and the form shows a Global (all tenants) switch when that applies. A global field is inherited by every workspace: everybody can fill it in, and nobody but a platform administrator can edit, reorder or delete it. Global fields also skip the per-workspace field quota.

What custom fields are not

A few things people reasonably expect of them, that they deliberately do not do.

• They are not a substitute for a real feature. A custom field stores and displays an answer; it does not calculate anything, trigger anything, or appear in a report you have not built.
• They are not an access-control mechanism. The Sensitivity setting is a label. Field-level security, configured on roles and user groups, is the thing that actually hides a field.
• They are not a full document library. File and Image each hold one managed reference, not a version history or a gallery — broader attachment workflows belong to the record's own attachment features. Attaching a new File or Image value isn't available from this screen yet; both types can be defined and an existing value can be viewed or cleared.
• They are not free-form. Every field has exactly one value type, chosen up front and permanent, and every value is checked against it on the way in.
• They are not retroactive. Tightening a field — making it required, or attaching a format check — never goes back and re-checks answers that were already saved.

Where to go next

The rest of this section covers each part in full.

Permissions

Working with definitions needs permissions of its own. Filling in a field somebody else defined needs nothing beyond access to the record itself.