Custom User Fields

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.

Maintaining the Values

A profile field is only useful while its value is true.

Where to find it

Architect Panel → Configuration:

• Custom User Information Fields — the fields

Architect Panel → Activity:

• Activity Log — changes to profile values

Stale data is worse than none

Because it is trusted. A department field last updated three years ago will be used to route work, build a distribution list or decide access — and it is wrong, silently, in a way an empty field would not be.

An empty field prompts somebody to ask. A wrong one does not.

Decide who maintains each field

• User-maintained — preferences, contact details, anything they know best.
• Administrator-maintained — department, role, internal identifiers, anything with consequences.

Use field security to enforce that rather than relying on convention. A field users can edit that drives access is a field users can grant themselves things with.

Attach updates to events

The only reliable way to keep profile data current. A department field is updated when somebody moves, because updating it is part of the move — not because somebody periodically audits profiles.

If a field has no event that updates it, it will drift.

Never let a profile field drive access

Access comes from groups. A profile field saying "manager" is a description, and if anything is granting permissions from it you have a permission model nobody can review — and one that may be user-editable.

Changes are audited

Profile edits are recorded with before-and-after like any other change, so "who changed my department" is answerable. Worth knowing for fields that matter.

Bulk updates

A reorganisation means many profiles changing at once. Plan for that — doing it record by record is slow and error-prone — and check the result rather than assuming the update did what you intended.

Review what is actually used

Periodically look at whether each field is populated and whether anything reads it. Fields that are empty for most people, or that nothing consumes, should go — they are unmaintained personal data.

Worked example

An organisation makes department and job title administrator-maintained and part of the internal-move checklist, and notification preferences user-maintained. A review found one field populated for eleven people out of four hundred and read by nothing — it was removed.

Recommendations

• Attach updates to events, not to audits.
• Enforce who maintains what with field security.
• Never drive access from a profile field.
• Remove fields nothing reads.