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.