People Operations Without Losing the Thread

This chapter examines how Ever Gauzy carries a person from recruiting into organization-specific work. The important question is not whether Gauzy has an applicant-tracking screen or an employee directory; it is how candidate, user, employee, team, project, policy, approval, and time-off records remain related as a person’s status changes. That relationship helps readers understand what Gauzy can coordinate across the employee lifecycle and where a schema still falls short of a complete HR or labor-compliance system.

The candidate is already in context

Gauzy’s candidate record belongs to a tenant and organization, so recruiting begins inside the same operating boundary as later employment. A candidate can have an application date, status, rating, hiring or rejection date, candidate level, weekly limit, billing-rate information, and a source. The record can also be connected to contact information, a user account, a possible employee record, a position, employment type, department, skills, tags, interviews, education, experience, documents, and feedback.

This design makes the candidate more than a name in a pipeline. A recruiter can record interviews and feedback; a manager can relate the candidate to a department or position; an organization can retain documents and skills; and a later hiring decision can connect the person to the working identity used by projects, teams, and time tracking. The same organization scope that determines who may view a project can determine who may view a candidate’s documents or compensation-related fields.

The candidate-to-employee relationship is especially significant. Gauzy represents a user as an authenticated account and an employee as an organization-specific working record. A candidate can have a user relation and an optional employee relation. When a person is hired, that relationship provides a path into the employee model without requiring the rest of the platform to invent a second identity. It does not mean that hiring is a fully automated or universally standardized transition. The repository shows the records and relations available; an organization still defines its approval, verification, onboarding, and data-retention process.

The lifecycle is best understood as a set of state changes around a stable organizational context:

stateDiagram-v2 [*] --> Applied Applied --> Interviewed: interviews and feedback Interviewed --> Hired: hiring decision Interviewed --> Rejected: hiring decision Hired --> EmployeeActive: organization employee record EmployeeActive --> Assigned: team or project assignment Assigned --> GovernedWork: time, expense, goal, and task records EmployeeActive --> GovernedWork: policy and approval records EmployeeActive --> EmployeeInactive: end of active employment EmployeeInactive --> [*]

The diagram describes the meaning of the relationships, not a claim that every installation enforces these exact state names or transitions. The candidate entity supports applied, hired, and rejected dates and statuses, while the employee entity supports active state, work dates, and organization-specific relationships. The transition between them is a business process that may include decisions not represented by a single field.

That distinction matters when a candidate is rejected or hired. A rejected candidate may still have interview feedback and documents that require an appropriate retention rule. A hired candidate may need a new team, position, rate, or tracking policy before they can participate in a project.