Onboarding

The Tasks screen is a single table of onboarding work across the organisation: the task, the employee it belongs to, the owner responsible for it, the due date and the current status, with the available actions right on the row. Because everything lives in one list rather than per-person silos, HR can see the whole onboarding pipeline at once — who is waiting on what, and which items are overdue for attention.

Creating a task takes seconds. The New task dialog asks for the employee — picked from the live employee directory — a task title, an owner and a due date. The owner is free text, deliberately, so a task can belong to a team rather than a person: HR, IT, Admin, whoever actually has to act. The employee is optional too, so general preparation tasks that are not tied to a specific joiner can sit on the same board.

Every task carries one of three statuses: pending, in progress or done. A pending task can be started or completed directly; an in-progress task can be completed; a done task can be reopened, which returns it to pending. The buttons on each row change with the status, so the interface only ever offers moves that make sense.

The same rules are enforced on the server, not just in the browser. Each transition checks the task's current status first and refuses an invalid move — only pending tasks can be started, and only completed tasks can be reopened — so two people working the same list cannot push a task into a contradictory state. Reopen matters more than it sounds: when a laptop comes back faulty or a signed form turns out to be the wrong one, you reopen the original task and the record shows the true history rather than a duplicate.

The Checklists screen is a register of the onboarding checklists your organisation recognises. Each entry records a checklist's name, the department or role it serves, the owner who maintains it, and an active or inactive status. A software house might keep one entry for engineers, one for sales and one for back office; a factory might keep one per station. When a process is superseded, its entry is marked inactive rather than deleted, so the record of how things used to be done survives.

The register documents the process; it does not script it. Creating a new hire's tasks is a deliberate, manual step on the Tasks screen, made with the checklist the register says applies. Entries are edited inline — open a row, change the fields, save — and removed only after an explicit confirmation, so the register stays deliberate rather than accumulating accidents.

The Documents screen tracks every document a new hire must submit or sign. Each row names the document, the employee it belongs to, its type — ID, Contract, Certificate, Bank, Tax or Other — a due date, and a status that moves from pending to submitted to verified. That last step is the important one: submitted means the paper arrived; verified means someone in HR actually checked it.

Because each document row is keyed to the employee record, filtering the picture for one person is a matter of reading the employee column — and the same edit-and-confirm-delete discipline as the checklist library applies here.

The Settings screen captures the decisions behind the process. Under General Setting, a Flow section records your policy preferences as stored settings — an 'Auto-assign checklist on hire' toggle, a 'Notify assigned buddy' toggle and the probation period in days, chosen from 30, 60, 90 or 180. The two Yes/No toggles are recorded preferences: they document the policy your organisation has decided on, rather than triggering any automation of their own. A Documents section records whether documents are mandatory for your organisation.

A second tab, Document Types, holds your own list of document types — add ID Card, Contract or anything else your organisation collects, and remove entries as policy changes. Everything on this screen is saved into the organisation's shared configuration store, the same place other Nexa People modules keep their settings, so it is set once per organisation rather than per user.

Onboarding is a tenant-scoped module: it appears in the navigation for organisation roles, and employees signed in to self-service do not see it. On top of that coarse rule sits the Role Templates permission matrix — the module is registered in the catalogue as Employee OnBoarding, and a role that holds no permission key in the module loses the route entirely.

The navigation menu and the route guard share a single source of truth, so the menu never offers a link the guard would then bounce — and typing the URL directly is held to exactly the same rules as clicking it.