The distinction between a person and a user is the most important one in the platform's data model — and the one most often confused on first encounter. They are different things, even when they refer to the same human being.
Person
A person is a record of someone in your organisation's talent universe. The Person entity exists whether or not the human has a login account.
A person can be:
- A candidate — someone who applied through the public portal but has not yet been hired.
- An employee — someone who works at the organisation.
- A former employee — someone who used to work at the organisation.
Person records carry: name, contact details, CV (if uploaded), linked competency profile, growth plan (if employee), assessment history, role, line manager link, and team membership.
Person records also carry these optional Saudi-context fields: nationality (ISO-2 code, e.g. SA, EG), National ID / Iqama (single 10-digit number, no discriminator), and the 4-part Saudi name (first, father, grandfather, family) used for formal display. These fields are populated either through the public apply form (for candidates) or through the invite-acceptance screen (for new employees). See Saudi fields for details.
User
A user is a login account in your workspace. The User entity exists if and only if the human can sign in.
A user has:
- A login email and a password (or in v0.6+, an SSO identity).
- Either one workspace role (staff) or a portal type (employee, candidate, trainer).
- A scope of access derived from that role: its permissions and its data scope.
How they relate
Three cases:
- A person with no user. This is most candidates and any former employee. They have a Person record (so the platform can hold their CV, history, and assessment data) but they cannot sign in.
- A user with no person. This happens transiently — when an HR admin signs up at workspace creation, they exist as a User before they have an associated Person. The first time they appear in the People roster, the platform creates a Person record and links it.
- A person with a user. This is every active employee, every line manager, and every HR admin once they have been on the platform for a moment. The Person and User are two records linked by a foreign key; they describe the same human from two angles.
Why two entities
Three reasons:
- Candidates need records before they need accounts. The platform stores CVs, screening results, and interview notes for candidates who never sign in. A pure user model could not hold this data without inventing dummy logins.
- Former employees need records after their accounts are gone. When someone leaves, their User account is removed but their Person record persists for organisational memory and audit. A pure user model would have to either keep dead accounts or destroy organisational history.
- Authorship and authentication are different concerns. What you authored (a role, an assessment template, a plan edit) is bound to the Person. Whether you can sign in right now is bound to the User. Separating them lets us preserve authorship even when access is revoked.
In the UI
- The People roster at
/{slug}/app/peoplelists Person records. - The Team management page at
/{slug}/app/settings/teamlists User records. - A person's profile (
/{slug}/app/people/{personId}) shows their full record; a user's row in Team management shows only login-related details.
The two pages serve different needs. People is for talent management. Team is for access control.
Things this distinction explains
- Why a candidate can have a CV and assessment history without ever logging in. Person records do that work.
- Why removing someone's User does not delete their assessment history. History belongs to the Person, which is preserved.
- Why hire is an atomic transaction that flips a Person from CANDIDATE to EMPLOYEE. The Person is the same entity throughout; only its status changes.
- Why a User can have one and only one Person link per workspace. A login identifies one human; a human is one Person in your workspace.