A person's profile has a fixed part — name, photo, city, timezone — and a part the company defines for itself: its own fields. Job title, employee number, start date, office: whatever this company needs, this company creates.
Kinds of fields
| Kind | What it holds | How it is validated |
|---|---|---|
| Text | Free text | Not validated |
| Number | A number | The value must read as a number |
| Date | A calendar date | Written as 2026-08-30 |
| Select | One option from a list | The value must be one of the field's options |
| Person | A person from the company | The value must name an active member |
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 accumulated value in the company failing its own validation, silently.
The person kind is what makes a profile more than a form: such a field holds the person, not a name, and the product can walk it. The whole organization chart is built from one field of this kind.
Who configures
Fields are created, renamed, disabled and deleted by whoever holds the company's system settings right; company administrators hold it by what they are. Creation takes a name, a kind and, for a select, the options.
- A field can be disabled: it stops being shown and accepted, but the values stay. Enabling brings everything back.
- Deletion erases the field with every value in every profile. Before deleting, you see how many profiles hold a value — what exactly will be erased is known before, not after.
- Field names are unique per company, case-insensitively.
- A value is limited to 2000 characters; a select option to 120.
Who fills in, and who sees
People fill in their own values, on their own profile. Whoever holds the right to manage people can fill in and correct anybody's values — a wrong value is wrong no matter whose hand writes it, so the checks are the same at both doors.
Values are visible wherever the person's profile is visible inside the company. On the organization chart, only fields explicitly flagged for the chart are shown, and only when filled in; a person-kind value is drawn as the person's name, not an identifier.
Validation
A value is checked on the way in, not on the way out: a value written wrong would have to be re-judged by every reader, and the first reader that matters is the organization tree, which cannot draw a manager out of a typo. A refusal names the field — somebody filling in six of them needs to know which one.
The person kind has one more rule: nobody reports to themselves. A value that closes a person onto themselves in the manager field is refused immediately.
Profile fields and search
Profile fields do not take part in issue search: QQL asks about issues, not about people. The one bridge between the profile and search is the manager field, which the myReports() and myVertical() functions answer by.
A person's profile fields and custom issue fields are different things: the former live on a person's profile and are configured in system settings, the latter live on issues and take part in search.