Hailey HR – Gotchas

Hailey HR supports "parallel employments" (multiple Employment records per employee). department_id, department_name, division, division_id, company_id, company_name, title, team, manager.id, and employment_role.type reflect the employee's effectual employment — the active one, or when none is active the next-to-start, or failing that the most recent ended one (status precedence: active → will-start → ended). priority is a manual, user-ordered rank that is deliberately not recalculated when an employment ends, so it does not by itself indicate which employment is current. employment_start_date/employment_end_date reflect overall company tenure instead — see "Get Employee" for per-employment detail via jobs[]. An employee can also hold multiple titles and belong to multiple teams at once (titleIds/teamIds arrays). We only return the first of each as title/team, since the unified schema allows a single value for both.

Hailey HR does not allow duplicate email addresses across employees. Creating an employee with an emails value already in use by another employee returns an error.

Hailey HR supports "parallel employments" — an employee can hold more than one Employment at once. Fields that describe a single current position (department_id, department_name, division, division_id, company_id, company_name, title, team, manager.id, employment_role.type, probation_period.end_date, and employment-level values in custom_fields) reflect the employee's effectual employment: the active one, or — when none is active — the one that will start next, or failing that the most recent ended one (status precedence: active → will-start → ended). employment_start_date/employment_end_date reflect overall company tenure (earliest start / latest-or-open end across ALL employments), not the effectual one. Every employment is listed in jobs[], flagged via is_primary, with its own start_date/end_date.

Each employment also carries a manual priority rank set in Hailey HR's UI. priority is a user-ordered value that is deliberately not recalculated when an employment ends, so an ended employment can keep priority: 1 indefinitely — it is not a marker of which employment is current. When more than one employment shares the winning status, the lowest priority is currently used to break the tie.

An employee can also hold multiple titles and belong to multiple teams at once (titleIds/teamIds arrays). We only return the first of each as title/team, since the unified schema allows a single value for both.

Salaries carry a history[] of effective-dated amounts — a raise adds a new dated entry rather than replacing the old one. compensations[].rate/effective_date reflect the entry with the most recent date that has already passed, not just the last entry added.

HaileyHR returns time off as one entry per calendar day, with no request-level identifier and no date range. Unify surfaces each day as its own time-off request, so start_date always equals end_date. A multi-day booking therefore appears as one request per day rather than a single spanning request. Day-based entries report units days (a full day = 1, a half day = 0.5); entries booked in minutes report units hours (minutes / 60). Unify does not merge consecutive days into a span: HaileyHR provides no request boundary, so calendar-adjacency alone cannot tell two separate same-reason bookings apart from one longer booking.

Pagination is not supported. HaileyHR's /TimeOff returns the full company dataset in a single response with no native paging, and there is no stable per-request identifier to page on. The limit and cursor parameters are not honored — retrieve the full list in one call.