Apart from a fixed part (name, photo, city, timezone), every profile field is the company's own to define. Job title, employee number, start date, office: whatever this company requires, this company creates.
Kinds of fields
| Kind | What it holds | How it is validated |
|---|---|---|
| Text | Free text | Its length, within the company's short-text limit |
| A number | A number | The value must read as a number |
| A date | A calendar date | Written as 2026-08-30 |
| One of a list | One option from a list | The value must be one of the field's options |
| Somebody who works here | A user from the company | The value must name an active member of the company |
The kind is chosen at creation and never changes: a field that held dates yesterday holds dates today. Turning it into a select would leave every value the company has accumulated wrong, and silently so.
A field of the user kind is what makes a profile more than a form: it holds the user, not a name, and the product can walk it. The whole organization chart is built from one field of this kind.
Who configures them
Fields are created, disabled and deleted by whoever holds the company's system settings right. Company administrators always have it. Creation takes a name, a kind and, for "One of a list", the options.
- A field can be disabled: it stops being shown and stops being accepted, but the values stay. Enabling it brings everything back as it was.
- Deletion erases the field together with every value in every profile. Before deleting, the product shows how many profiles have a value in the field: what exactly will be erased is known beforehand, not afterwards.
- A field name is unique in the company, and case does not matter.
- A text value is limited by the company's short-text limit (60 characters by default, 10 to 500 in the system settings), and a select option to 120.
Who fills them in, and who sees them
Users do not fill in these values on their own profile. The values of any member, one's own included, are filled in and corrected on the user's page by whoever holds the "Edit user profiles" right. The checks are the same no matter who writes them.
Values are visible wherever the user's profile is visible inside the company. On the organization chart the chart shows only the fields explicitly flagged to appear there, and only the ones filled in; a field of the user kind is drawn as the user's name, not as an identifier.
Validating a value
A value is checked on the way in rather than on the way out: every reader would have to second-guess a value stored wrong, and the first of those readers is the organization tree, which cannot draw a manager out of a typo. The rejection names the field that failed the check: somebody filling in six fields needs to know which one is wrong.
A field of the user kind has one more rule: no reporting cycle. A value that would make a user their own manager, directly or through a chain of managers, is rejected at once.
Profile fields and search
Profile fields do not take part in issue search: QQL asks about issues, not about users. The one bridge between a profile and search is the manager field, which the myReports() and myVertical() functions use.
A user's profile fields and custom issue fields are different things: the first live on a user's profile and are configured in system settings, the second live on issues and take part in search.