Employee lifecycle

User guide › Employee lifecycle

Start here: a member is not an employee

Almost every confusion on this page traces back to one distinction, so it is worth getting straight before anything else.

All three combinations are normal and supported:

• Both — a manager who signs in and is on the books.
• Member, no employee — an external accountant given portal access, or a service account.
• Employee, no member — retail, warehouse and kitchen staff who never sign in. They still get a contract, a shift and a place on the tabel.

When both exist, the member link on the employee record is the join. It is what lets HR Records, Onboarding and Leave & Attendance describe one person without any of them reaching into another's data. If that link is blank, the person's self-service screens have nothing to show them — which is the single most common support question on this page.

The whole lifecycle in one table

1 · Hiring

People → Hire someone (/hrm/people/hire). One form — name, work email, position, department, manager, work type, start date, salary — and everything downstream follows from it. The screen needs the Manage employee records action on HR Records, so a non-admin HR manager can run hiring without being made an admin.

1. The employee record is created first

   Before the invite, before anything else. That ordering matters: it is what gives the contract something to be generated from, and it means HR's data has a home even if the person never accepts — or is never invited at all.

   The member link is deliberately left empty at this point. Nobody has an account yet.

2. The hire terms land on their own record

   Salary is not a field on the employee record. It lands on an employment record — a dated event — so a later raise doesn't overwrite the hire figure and "what were they paid in March" keeps one answer.

3. The position is marked filled

   If you picked a position and nobody currently holds it. A seat already held is left alone: handovers legitimately overlap, and silently evicting the current holder would be worse.

4. The invite is optional

   The checkbox needs a work email and turns off without one. Plenty of employees never sign in and are still employees — they get a contract, a shift and a tabel row all the same. Leave it off and you get an employee record with no login, which is a perfectly normal end state.

2 · Giving them a login

An invite creates a pending invite, not an account. The account exists the moment they accept — see Members, teams & seats for expiry, resending and the manual "Add member" alternative.

What matters here is the join. When the invite is accepted, the new member is matched back to the employee record on their email address — the work email first, then the personal one — and links to it. No second employee record is created. Email is the match because the invitee chooses their own display name at accept time, so HR could not possibly have known it when they filled the form. Only employee records with no member link are candidates, so an accepted invite can never steal somebody else's record.

The Directory shows this state as a badge on each person: Invite pending while an unexpired invite is outstanding, No account otherwise. That is deliberately a separate badge from the employment status — somebody can be employment-Active and have never opened their invite, and collapsing the two is what made that invisible. Their 360 profile carries the same badge with Copy invite link and Resend next to it, so you don't have to go hunting through Members.

3 · If they already work here

Switching HR Records on at a company that already has thirty members is a different act from hiring, and it has its own screen: People → Add existing members (/hrm/people/activation, Manage employee records).

It lists every member with no employee record and asks you to place each one: Staff, External (agency and third-party people on site but not employed here), Former staff (created as terminated, so your turnover history exists from day one), or Not staff — which creates nothing and remembers, so the same service account isn't proposed again next month. Obvious staff are pre-selected; anything that looks automated starts on Not staff with a badge saying so.

Re-submitting the screen is safe. Everything is matched against the current state of the workspace, not against what the page believed when it loaded, so a stale tab can't resurrect somebody you ruled out or create a second record for somebody already linked.

4 · The onboarding journey

You don't start it. The moment an employee record is created, the Onboarding app raises a journey — the merge of every journey template that applies to that person's job, department and work type, instantiated as dated, assigned steps.

Installing the app ships four defaults, so the very first person you hire gets a real journey without anyone authoring anything: a new-starter checklist, a leaver checklist, a records catch-up for existing staff, and an external/agency variant. Editing them is the Journey builder (/hrm/onboarding/builder, Manage onboarding journeys).

That split is the point: a new hire and a training manager are exactly the people who don't hold HR capabilities, so their pages can't be gated on one.

Steps do real work rather than being checkboxes — send a contract for signature, hand over a laptop from the asset register, collect a document, route a department training sign-off, raise an approval. A step dated before day one is normal and intended: "send the contract three days before they start" only works because the employee record exists before the person does.

5 · What they can actually open

This is the section worth reading twice, because it is where "I added them, why can't they see anything" gets answered.

All three HR apps ship restricted. A brand-new member has no access to any of them until you grant it under Settings → Module Access. Expanding an app there reveals the individual actions it offers:

The screens that write for other people — hiring, activation, the HR policy questionnaire, the roster, the shifts editor, the kiosk, the tabel, the journey builder, the approvals inbox and the Leave & Attendance and Onboarding consoles — each sit behind one of those actions. The screens that are about you never do.

If someone only ever needs the HR corner of the workspace, there is an HR seat — a restricted seat gated to exactly these three apps plus the personal baseline. It opens on their own profile. A seat gate decides which apps someone can be granted; you still grant module access inside it. See Members, teams & seats.

6 · Day to day

Their own profile

People → My profile (/hrm/people/me) is their own record in full — including the personal details that are stripped from everybody else. Nobody needs a capability to read their own bank account.

What they may edit is a fixed server-side list: phone, personal email, address, the emergency-contact fields, bank details and date of birth. Anything else in a saved payload is dropped silently, on a record resolved from their own member link — so self-service can never become a promote-yourself or un-terminate-yourself path. Fields only HR can write are named separately on the page as "HR fills these in", because "fill this in" is useless advice for a field you can't touch.

If they have no employee record linked to their account, the page says so plainly: "You don't have an employee record yet — ask HR to link your member account to your employee record, and your profile appears here."

Booking leave

Leave & Attendance → My leave (/hrm/my-leave), on plain app access. They pick a type, pick dates, and submit — one action, which starts the approval workflow immediately.

• The day count is worked out on the server from their location's working week and its public holidays, so a request spanning a holiday doesn't spend a day of leave on it.
• Balances are derived, not deducted — the type's entitlement for the year, minus the leave of that type they've already had approved. Nothing is decremented anywhere, so there is no stored counter to drift.
• Entitlement comes from the leave type, not from the person. There is no per-person override.
• A waiting period is per type. A type they aren't eligible for yet shows "Eligible from <date>" instead of a balance and can't be submitted.

Eligibility and accrual both count from the hire date. When HR Records is installed, that is the hire date on the employee record — HR Records owns it, and Leave & Attendance reads it rather than keeping its own answer. Change it in People and the balance moves. If the employee's hire date is blank, the staff row's own value is used rather than showing a blank.

Clocking attendance

Leave & Attendance → Attendance (/hrm/attendance), also plain app access: check in, take a break, check out. Sessions are keyed to the signed-in member, so this works for anyone with the app — no staff row needed.

Each location can carry a check-in policy — GPS inside a geofence, being on the office Wi-Fi, either, or both. The check is made on the server from raw signals the device sends; the client never decides pass or fail, and a refusal comes back in plain language ("you're ~2.3 km from Tbilisi HQ"). A location with nothing configured simply doesn't gate.

The Kiosk (/hrm/kiosk) is a different thing: a shared device an operator runs, posting check-ins on behalf of other staff. It sits behind Manage attendance, and its taps are exempt from the presence gate — the device is already at the office.

7 · The manager's side

Approving leave

Leave & Attendance → Approvals (/hrm/approvals), behind the Approve leave action. It lists every submitted request with the requester, type, dates and reason, and approves or rejects inline. A rejection requires a comment.

Rostering and the tabel

The Roster (/hrm/roster), Shifts (/hrm/shifts), Tabel (/hrm/tabel) and the Leave & Attendance Console (/hrm/console) all sit behind Manage attendance.

The roster grid shows the effective week — default shift, plus overrides, plus approved leave, plus holidays, merged for you — and a cell click covers the three edits managers actually make: change that day's shift, give a day off with an optional make-up day, or swap two people. The tabel is the monthly grid, printable, with any cell overridable by hand.

Both are built from staff rows. Somebody with an employee record but no staff row simply isn't on them — which is what Set up work on /hrm/staff (behind Manage staff) exists to fix. It creates the work side of a person who already exists in HR Records; it doesn't create a person. People are added once, in People.

Keeping the record honest

The HR console (/hrm/people/console) is the weekly sweep: headcount by department, joiners and leavers this month, probations about to lapse with no verdict recorded, documents about to expire, unfilled positions, assets currently out, birthdays and work anniversaries. Every tile links through to the records behind it.

Probation deserves a mention because it costs money to miss: it is tracked as a period with an outcome, not as a status somebody remembers to change, and a daily reminder chases the evaluator and the employee's manager before it lapses. Extending a probation genuinely moves the deadline rather than leaving two competing dates.

8 · When they leave

1. Set the employment status

   On their employee record, move the status to Notice or Terminated. That transition is what raises the offboarding journey, dated from the termination date. Notice counts deliberately — offboarding that starts on somebody's last day is a list of things nobody did.

   It only fires on the transition, so re-saving an already-terminated record raises nothing. This is also the one thing a backfilled employee does get: they never onboarded, but they can certainly leave.

2. The journey collects the company's property back

   An asset step on an offboarding journey runs the return leg against the equipment they currently hold, so the laptop comes off their name and the condition it came back in is recorded against the asset. The default leaver template also carries an exit interview and a final-documents step, both routed to HR.

3. Close their account — separately

   Termination is an HR fact. It does not end their sign-in, and there is no deactivated state to put them in. Removing the member is its own act, under Settings → Members & Permissions, and it releases their direct grants, role and team memberships and any gate seat. See Members, teams & seats.

4. What survives

   The employee record does — including their employment history, documents and the termination itself. That is the point: turnover reporting, and "who held this position before", have nowhere else to live. Records they owned elsewhere in the workspace become unowned rather than being deleted.

When it doesn't line up

"The new joiner can't sign in"

Work down this list; it is nearly always one of the first three.

• Was an invite actually sent? The hire form's invite checkbox needs a work email and turns off without one. Open their profile — a No workspace account badge means no live invite exists.
• Is workspace email connected? Without a sender the invite is created and the email isn't. Use Copy invite link from their profile, or Members → Pending invites.
• Has it expired? Invites last seven days and drop off the list on their own. Resend for a fresh one; resending an unexpired invite reuses the same link, so a link you already handed over keeps working.
• Are you at your seat cap? Accepting an invite is refused outright when the plan's user limit is reached, and while billing is past due.

"They signed in, but the HR apps aren't there"

All three ship restricted, and the invite HR sends carries no roles and no grants by design. Grant them under Settings → Module Access. Plain access is enough for My profile, My leave, Attendance, My onboarding and My assignments — those are the screens a new joiner needs, and none of them requires a named action.

If they're on a restricted seat, check the seat's gate as well: the gate decides which apps they can be granted at all, and a grant outside it does nothing.

"They can see the app, but My profile is empty"

Their account isn't linked to an employee record. The page says as much rather than erroring. Two usual causes:

• They joined under an email the record doesn't carry. The link is made on the employee record's work email, and failing that its personal email. An address in neither field matches nothing.
• Somebody created the employee record by hand in the raw Employees table and left the member link blank. Open the record and set it.

Check the Directory badge first — it tells you the state without opening anything.

"They can't see their own leave"

• Do they have the Leave & Attendance app at all? My leave is plain access, but it is still access.
• Is the balance zero rather than the page empty? Then it's eligibility: a leave type can carry a waiting period, and an ineligible type shows "Eligible from" and refuses submission. Eligibility counts from their hire date — the employee record's hire date when HR Records is installed. A blank one and a wrong one produce very different balances.
• Is the entitlement on the leave type set? Allowance is per type, not per person; a type with no entitlement gives everybody nothing.

Note that a granted app does not give them the Leave requests entity. If you send them to the raw /hrm-leave-requests table they'll see an empty grid and conclude their request vanished. Send them to /hrm/my-leave.

"Their manager can't approve"

• Do they hold Approve leave? Without it, the Approvals page isn't in their nav at all.
• Are they on the approver list for that leave type? This is the usual answer. The capability gets you the page; the approver configuration decides whether you can act on a given request. Anyone else gets a plain "You're not on the approver list for this step" rather than a silent failure.
• Did you assume being someone's manager is enough? It isn't. Approvers are named people or roles, set per leave type on the Approvals page's settings panel. Nothing routes automatically up a reporting line.
• Being an admin isn't automatically enough either. A leave type with nobody configured falls back to a workspace admin — which is why it usually looks like admins can approve everything — but a request routed to a named approver is that approver's to decide.

"HR can't see salary or personal details"

Salary, personal ID, date of birth, personal email, home address and bank details are removed from the response by the server for everyone except admins — not hidden in the interface, actually absent. Two things follow:

• Grant See compensation / See personal data to open them back up. Every reveal is written to the audit log.
• Those capabilities work on HR Records' own screens — the 360 profile, My profile — and not in the generic entity table or record drawer, where the admins-only floor still applies. If the profile shows a salary and the raw table doesn't, that is working as designed.

Confidential documents behave the same way per row: the fact a document exists stays visible so expiry chasing still works; the file itself is withheld.

"Nobody got an onboarding journey"

Nothing errors when no template matches — no journey, no message — so work down this list:

• Wrong kind. An onboarding template never matches a leaver.
• The template is switched off, or is marked Start by hand only — a different statement from inactive, and the shipped records-catch-up default carries it.
• A filled scope axis doesn't match exactly. "Retail Ops" is not "Retail", and the department tree is not walked — somebody in a team under Retail does not match a Retail-scoped template.
• The template is scoped to a job and the person has no position, or their position has no job.
• A journey of that kind is already running. A second one is refused.
• They were created by the activation screen. Backfilled people never onboard, on purpose.

The builder's effective preview answers all of these directly: type in a department, job title and work type and it lists which templates matched, with what each one contributed.

"We hired them twice"

You shouldn't be able to. The hire form refuses a second record for an email that already has one, and an invite accepted by someone already linked is a no-op. Genuine duplicates almost always mean two different addresses — one record filed under a work email, a second created when they joined using a personal one. Compare the email fields, keep the record with the history, and link the member to it.

"We removed them and their records vanished"

The employee record doesn't vanish — removing a member and removing an employee are different acts. What does change is ownership: records elsewhere in the workspace that the person owned become unowned, and unowned records are invisible to anyone whose grant is "View own". If the person leaving had a pipeline or a caseload, reassign it before deleting the account.

"We removed them and they're still in the tabel"

Roster and tabel are built from staff rows, which are separate from both the member account and the employee record. Deleting the account doesn't remove the staff row, and neither does terminating the employee. Deactivate the staff row on /hrm/staff when someone stops working shifts. Their historical tabel and attendance stay, which is what you want for a period you've already closed.

Where to go next