User custom fields

Custom fields add agreed profile data that is not part of the standard employee card, such as an internal number or start date. Administrators open /custom-fields; creating a field does not by itself define where it is shown or who can see it because that depends on portal configuration.

Field list

The table or mobile list shows code, name, type, multiple/required flags and sort order. Refresh reloads the list. An empty state means no fields were returned; a load error must not be mistaken for deleted data.

Create and edit

Select Add. On creation, code is optional (the portal may generate one), while name is required. Choose a type, sort order and settings. Supported types are string, number, boolean, date, datetime, enum, user and department; a field can be multiple and required.

When editing, code is read-only. Change name, type, flags, order and settings only after checking existing profiles. Settings accepts JSON and invalid JSON is rejected. Define enum values and selection rules for user/department before publishing.

Delete and consequences

Deletion requires confirmation and is irreversible for the field definition; this screen has no undo or restore action. Check usage and whether values must be retained first; when possible, disable or hide a temporary field through portal configuration instead.

Access and display

Only an administrator can create or change fields. A field does not grant profile or PII access. The exact place where employees fill and view it (profile, edit form or directory) must be confirmed in your configuration; the current screen does not make this relationship explicit.

The /custom-fields screen currently manages the field schema: listing, editing, and deleting definitions. Do not promise that a value already appears in an employee profile or directory until the deployed portal build shows the input and saved value there. If a field exists but its value is not visible, check the display surface and permissions separately; do not treat that alone as data loss.

Safe review

Use synthetic names and values. Keep real PII, secrets, and internal identifiers out of examples and demonstration data. Before handing over a configuration, check that type names and flags are clear in the portal language and that field visibility matches the required permissions.

Related: Portal administration, Access and roles, Profile.