Custom data fields
Institution-defined attributes on user profiles — how they differ from custom columns, how to set values, and how to request missing information from users.
Custom data fields are institution-defined attributes stored on each user profile — for example a matriculation number, scholarship flag, or advisor code. Every field is defined once for the institution; each user then holds a value (or a blank) for that field. Values appear on the profile Overview tab and, when configured as custom columns, as cells in the Users table.
Staff can enter values themselves, set them during user creation, or request missing information from the person so they complete their own profile.
Why it matters
No two universities share the same directory schema. One needs an external campus-card ID; another tracks visa status; a third stores a preferred student-services desk. Custom data fields keep that metadata inside Fuxam instead of in side spreadsheets that drift out of sync with enrollment and access.
Requesting missing data matters just as much as defining fields. After a large intake, registry teams often discover incomplete records — missing dates of birth, blank custom identifiers, empty statistics attributes. Asking users to supply what only they know is faster and more accurate than staff guessing or emailing ad hoc forms.
How it fits
| Related area | Relationship |
|---|---|
| Custom columns | Display and inline editing of the same field definitions in the Users table |
| Create a user | Optional values can be entered at account creation |
| Edit a user | Staff update values on Overview or in table cells |
| Contact details | Emails, phones, and addresses — separate from custom data fields |
| Roles and permissions | Who can define columns and edit values |
| Bulk actions | Edit Custom Fields for many users at once |
Key concepts
| Term | Meaning |
|---|---|
| Custom data field | An institution-wide field definition plus each user’s stored value. |
| Custom column | The Users-table presentation of a custom data field. |
| Field type | Validation rules for the value — text, number, date, select lists, or auto-generated ID (see Custom columns). |
| Personal field | Built-in demographic attributes on the user (for example date of birth, preferred name, nationality) that can be included in a data collection request. |
| Statistics field | Reporting-oriented attributes that may be filled from official statistics workflows. |
| Data collection request | A request for the user to supply one or more missing custom, personal, or statistics fields, optionally with a notification. |
Custom data fields vs custom columns
| Custom data fields | Custom columns | |
|---|---|---|
| Purpose | Store and manage profile attributes | Display and edit those attributes in the Users table |
| Where you work | Profile Overview, create form, data collection requests | Table headers, cells, bulk Edit Custom Fields |
| Audience | Process owners defining what must be captured | Day-to-day operators scanning and correcting lists |
| Handbook page | This page | Custom columns |
In practice, creating a User Data Field from the Users table both defines the data field and adds its column. Treat columns as the operational face of the same model.
Field value shapes
When you look up a user’s data fields, each entry typically includes a field name, a type (such as text, number, date, or yes/no), and the current value. Empty values are the usual trigger for a data collection request.
How to define and display fields
Defining a new attribute is done from User Management as a User Data Field, which also creates the matching table column:
Go to OrgHub → Management → Users.
Select Add, then User Data Field.
Choose a clear name and an appropriate type.
Save. The field is available on profiles, on the create form, and as a column in the table.
Full column management — rename, types, ID patterns, and column-level access — is documented in Custom columns.
How to set values as staff
On create
In the Add User form, fill any configured custom fields below name, email, and role when you already know the values.
On the profile
Open the user from OrgHub → Management → Users.
On the Overview tab, edit custom field values.
Save when the unsaved-changes indicator appears.
In the table or in bulk
Click a custom column cell to edit inline, or select many rows and use ⋯ → Edit Custom Fields. See Bulk actions.
Request missing information from users
When a profile is incomplete, you can create a data collection request for that user. The request lists the fields they should supply. Optionally, send a notification so the person is prompted to complete the missing pieces.
What you can request
A request can include fields from three categories:
| Category | What it covers | Examples |
|---|---|---|
| Custom | Institution-defined data fields | Matriculation number, scholarship code |
| Personal | Built-in demographic / identity attributes | Date of birth, preferred name, gender, nationality, place of birth |
| Statistics | Attributes used in official reporting workflows | Statistics-engine fields your institution maintains |
You select which fields are required in the request. Only include what you truly need — over-requesting slows completion and raises data-protection questions.
How to think about the workflow
Identify incomplete users — for example after an intake export or by scanning blank custom columns.
Decide which fields the user should fill versus which staff should correct (staff usually own institutional IDs; users usually own personal demographics).
Create a data collection request for the user, listing those fields.
Choose whether to send a notification so the person is alerted.
Follow up on the profile Overview until values appear; then clear any operational checklist you use for readiness (invite, cohort enrollment, and so on).
When to notify
| Situation | Suggestion |
|---|---|
| User is already active and checking Fuxam regularly | Send a notification |
| User has not activated yet | Complete personal data after invite activation, or collect via admissions first |
| Sensitive fields (nationality, date of birth) | Notify and explain purpose in your institution’s usual privacy wording |
| Staff-owned identifiers only | Prefer staff edit or bulk edit — do not ask the user |
Personal demographics on the profile
Alongside custom fields, user records can hold personal attributes such as:
- Preferred name
- Date of birth
- Gender
- Nationalities
- Birth name
- Country and city of birth
- An institution code / student code where used
These are not custom columns by default, but they can be included in a personal data collection request when missing. Keep them accurate for reporting, health-insurance workflows, and identity verification.
Access required
| Task | What you need |
|---|---|
| Define fields / columns | Permission to create user-management columns |
| Rename or configure columns | Permission to update user-management columns |
| Edit a user’s field values | Permission to update that user, plus column-level edit rights where used |
| Request missing data | Permission to update the user (and any institution rules for notifications) |
See Roles and permissions and Custom columns.
Best practices
- Design the field catalog before intake. Agree names, types, and who owns each value (staff vs user).
- Separate directory fields from curriculum. Enrollment belongs in cohorts; identifiers and flags belong in custom data fields.
- Use data collection requests for user-owned gaps. Do not leave blank date-of-birth or nationality fields for months after enrollment.
- Keep requests short. Three focused fields complete faster than a long list.
- Align with data protection. Only request what your retention and privacy notices cover; restrict who can view sensitive columns.
- Close the loop with columns. After users submit, verify completion in the Users table filters or exports.
Common pitfalls
| Pitfall | What happens | How to avoid |
|---|---|---|
| Confusing columns with contact details | Staff put phone numbers in free-text custom fields | Use Contact details for emails, phones, and addresses |
| Asking users for staff-owned IDs | Inconsistent formats and duplicates | Staff enter ID fields (or use auto-generated ID columns) |
| No notification on a request | Users never see the task | Enable notification when the person is active |
| Blank fields blocking other processes | Invites or reporting wait on incomplete data | Request missing data early in the onboarding checklist |
| Overloading custom fields with cohort names | Academic structure duplicated | Use study program cohorts for enrollment |
FAQ
Are custom data fields the same as custom columns?
They refer to the same underlying attributes, at different layers. Fields are the stored attributes; columns are how you see and edit them in the Users table. This page covers storage, personal/statistics categories, and data collection requests; Custom columns covers table display and types.
Can I request both a custom field and date of birth in one go?
Yes. A data collection request can mix custom, personal, and statistics fields in a single request.
Do data collection requests change the user's role or status?
No. They only ask for missing profile information. Account status and roles are managed separately — see Roles and permissions and Deactivate a user.
Where do emails and postal addresses fit?
They are contact details, not custom data fields. Do not model primary email or semester address as a free-text custom column if the dedicated contact sections are available.
Related pages
Custom columns
Display and edit fields as columns in the Users table.
Contact details
Emails, phones, and postal addresses on the profile.
Create a user
Set known custom field values at creation.
Edit a user
Update profile fields on the Overview tab.
Bulk actions
Edit custom fields for many users at once.
Roles and permissions
Who can define fields and edit values.