Adding Fields to Profiles
User profiles can carry fields of your own beyond what the platform holds.
Where to find it
Architect Panel → Configuration:
- Custom User Information Fields — the fields themselves
Architect Panel → Security:
- Permissions — restricting who sees a field
This article covers the practical task. The wider configuration-field family — user, tenant and instance fields together — is described under Development.
What belongs on a profile
Attributes of the person as a user of the system: their department, their job title, an internal reference, a preference the application acts on.
What does not
Anything that is really about a business record rather than about the user. A caseworker's caseload is not a profile field; a customer's order history is not a profile field. Those belong to datastores with their own relationships.
The test: would this still be true if they stopped using the system? A job title would; a list of their current cases would not.
Every field is data you now hold about a person
The question worth asking of each one: why do we need this, and for how long?
Profile fields are easy to add and quietly accumulate, and each is personal data about a member of your staff or your customers. A field added because it might be useful is a field you must justify, protect and eventually dispose of.
Restrict the sensitive ones
Field security applies here as anywhere. A profile holding anything about health, personal circumstances or protected characteristics should not be visible to everybody who can see a user record.
Note that people can often see their own profile — so consider what somebody being able to read a field about themselves implies, particularly for anything assessed rather than declared.
Use the right field type
The same discipline as any datastore: a date is a date, a choice is a dropdown, a phone number is a phone number. Profile fields are as susceptible to becoming unqueryable free text as anything else.
Keep the set small
A profile with thirty fields is one nobody completes and nobody trusts. Add what the application acts on.
Decide who maintains them
Some fields users maintain themselves, some are administrative. Being clear about which is which prevents both the field nobody updates and the field users overwrite.
Worked example
An organisation adds four profile fields — department, job title, internal staff number and a notification preference the application reads. Nothing about performance or personal circumstances is held here; that lives in an HR datastore with its own permissions and retention.
Recommendations
- Ask whether it is about the user or about a business record.
- Justify each field — it is personal data.
- Restrict sensitive fields and consider self-visibility.
- Keep the set small and the types correct.