Custom User Information Fields

The Configuration Field Family

Three parallel mechanisms let you add fields of your own to things the platform owns: users, tenants and the installation itself.

Where to find it

Architect Panel → Configuration:

• Custom User Information Fields — fields on user records
• Custom Tenant Information Fields — fields on tenant records
• Instance Configuration Fields — fields on the installation itself

The practical task of adding a field to user profiles and keeping its values current is covered under Users. This article is about the family and how to choose within it.

They share a shape

Each defines fields with a name, a type, validation, a default and whether it is required — the same metadata-driven approach the platform uses for datastores. That consistency means what you know about field types applies here too.

Which to use

• User fields — attributes of a person as a user of the system. Department, job title, an internal reference.
• Tenant fields — attributes of a customer or organisation within a multi-tenant installation. Their account manager, their sector, their contract reference.
• Instance configuration fields — settings for the installation as a whole.

The question that decides it

What does this value describe? One person, one customer, or the whole installation. Getting that wrong produces a value stored per user that should have been per tenant — which then has to be kept in step across everybody, and will not be.

They are not datastores

The commonest misuse. These extend records the platform owns; they are not a place to model your own data.

If you find yourself adding several related fields describing something that is not the user, the tenant or the installation, you want a datastore with a relationship — which gets its own permissions, audit, history and reporting.

Each field is data you hold

Particularly user fields, which are personal data about staff or customers. They accumulate easily because adding one is trivial, and each needs justifying, protecting and eventually disposing of.

Sensitive values are encrypted

Where a field is marked as such — which matters most for instance configuration, since that is where module credentials tend to land.

Do not drive access from any of them

Access comes from groups. A field describing somebody's role is a description; anything granting permissions from it is a permission model nobody can review.

Worked example

An organisation holds department and staff number as user fields, account manager and sector as tenant fields, and its integration endpoints as instance configuration. A proposed "current projects" user field was instead modelled as a datastore, because it described work rather than the person.

Recommendations

• Ask what the value describes — person, customer or installation.
• Use a datastore for anything that is really your own data.
• Justify every user field — it is personal data.
• Never grant access from a configuration field.

Where the Fields Appear

A configuration field is only useful where somebody can see and maintain it.

Where to find it

Architect Panel → Configuration:

• Custom User Information Fields — fields on user records
• Custom Tenant Information Fields — fields on tenant records
• Instance Configuration Fields — fields on the installation itself

Architect Panel → Security:

• Permissions — restricting who sees a field

Put them where the decision is made

A field maintained during onboarding belongs on the screen used for onboarding. One reviewed annually belongs somewhere that review happens.

A field on a screen nobody visits is a field nobody maintains, and stale configuration data is worse than absent configuration data because it is trusted.

Decide who edits each

• User fields — some are the user's own, some administrative. Enforce that with field security rather than convention.
• Tenant fields — usually administrative, sometimes visible to the customer.
• Instance configuration — almost always restricted; it frequently holds credentials.

Order and group them

As you would any form. A long flat list of unrelated settings is hard to work through, and the fields that matter get lost among the ones that rarely change.

Write help text

Configuration fields are edited rarely, by people who did not create them, often under time pressure. A sentence explaining what a field does and what a sensible value looks like is worth more here than almost anywhere else in the application.

"Timeout" is a field somebody will guess at. "Seconds to wait for the supplier's API before giving up — 20 is usually right" is one they will set correctly.

Set defaults that work

Most configuration is left at its default, so the default should be the value most installations want rather than an empty box that produces a broken feature until somebody fills it.

Validate

A configuration field with a wrong value breaks something, often far from the field. Validating at entry — a number in range, a properly formed address — catches it where it is cheap.

Keep the sets small

Configuration accumulates and nothing prunes it. A periodic look for fields nothing reads, or that are empty everywhere, keeps the screens usable.

Worked example

An organisation groups its instance configuration by module, with a sentence of help on each field and sensible defaults. Credentials are restricted to two administrators by field security. A review found four fields nothing had read since an integration was retired, which were removed.

Recommendations

• Put fields where the decision is made.
• Write help text — these are edited rarely and under pressure.
• Enforce who edits with field security, not convention.
• Prune fields nothing reads.