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.