Onboardora manual: setup, settings and daily use

Onboardora — User Manual

An onboarding register: a new starter's first ninety days as a dated plan — who owns each task, when it falls due, what is late, and what has actually been done. Version 1.0.3 [src: app/controllers/api.php:23].

About this manual

Every statement here was written by reading Onboardora's own source, and each one carries the file it came from in a bracketed src marker. Paths are relative to the folder this docs directory sits in. If a sentence disagrees with the application, the application is right and this manual has a bug.

Nothing is described that the code does not do. Where something is deliberately limited, or currently wrong, that is said plainly rather than left out.

⭐ Four properties the product is built on

The engine states them at the top of the file, and each one is worth knowing before you plan anybody's first week [src: app/src/Onboard.php:5].

A starter's plan is a snapshot. When somebody is added from a template, the template's tasks are copied onto them. Editing the template afterwards changes what the next person gets and can never rewrite a plan already in flight [src: app/src/Onboard.php:7] — the source compares it to the discipline a signed document gets, for the same reason: somebody is working to that list today.

Due dates are derived, never stored. A task carries an offset in days from the start date, so the date is computed at read time [src: app/src/Onboard.php:12].

"Late" is derived too — a task is late when it is not done and its derived due date has passed. There is no is_late column to go stale overnight and no job that has to run for the dashboard to be right [src: app/src/Onboard.php:17].

Completion is idempotent and keeps the first answer. Ticking a done task again does not move the time it was done or the name of who did it, because two people working the same checklist is the normal case, not the edge case [src: app/src/Onboard.php:21].

⭐ Moving a start date moves the whole plan

That is the practical consequence of derived due dates, and the source names what it avoids: no migration, and nothing left pointing at the old Monday [src: app/src/Onboard.php:14].

Executed — the same plan against two start dates:

start 2026-09-14   offset  −7  ->  2026-09-07      offset 30  ->  2026-10-14
start 2026-09-21   offset  −7  ->  2026-09-14      offset 30  ->  2026-10-21

Day −7 is a week before they arrive; day 0 is their first morning [src: app/src/Onboard.php:13].

One labelling detail worth knowing so you do not read the plan off by one: offset 0 is displayed as "day 1" — a starter's first morning is day one, not day zero. Executed:

offset  −7  ->  "7 days before"        offset  1  ->  "day 2"
offset   0  ->  "day 1"                offset 30  ->  "day 31"

Offsets outside the plan window are treated as typos

A plan lives between day −60 and day 365; outside that, an offset is a typo rather than a plan [src: app/src/Onboard.php:29], and the value is clamped rather than accepted. Executed:

−61  ->  −60        365  ->  365        'abc'  ->  0
−60  ->  −60        366  ->  365        '30'   ->  30

⭐ Calendar days, and a weekend that is shown rather than hidden

Phases are calendar days, not working days, and the reasoning is given in full [src: app/src/Onboard.php:67]: "day 30" in an onboarding plan means a month in, and a plan that quietly shifted because May had a bank holiday would be worse than one that did not.

The consequence is stated rather than smoothed over: a task that lands on a weekend is shown as landing on a weekend — the manager can see it and move it, which is more honest than the product moving it silently [src: app/src/Onboard.php:69].

Executed against a Monday start:

start 2026-09-14 (Mon)  + day 5   ->  2026-09-19  (Sat)
                        + day 6   ->  2026-09-20  (Sun)
                        + day 12  ->  2026-09-26  (Sat)

The plan groups by the phrases a manager actually uses rather than by raw day numbers [src: app/src/Onboard.php:64]. Executed:

day −7, −1  ->  before          day 14, 30       ->  month-one
day 0       ->  day-one         day 60, 90, 200  ->  ninety
day 1, 7    ->  week-one

Who owns a task

Six owner kinds [src: app/src/Onboard.php:33]: manager, HR, IT, buddy, the starter themselves, or a named person who carries their own name and email. The first five resolve off the starter's own record, so reassigning a manager does not leave a task pointing at somebody who left.

Reassignment is its own operation rather than a free-text edit [src: app/src/Onboard.php:269].

Users and roles

Three roles [src: app/controllers/v3.php:60]. A member can edit a starter, tick tasks and edit them; admin holds everything [src: app/controllers/v3.php:61].

A viewer is granted audit.view explicitly, written into the role by name rather than picked up by a wildcard [src: app/controllers/v3.php:60], and the audit page requires exactly that [src: app/controllers/v3.php:379]. In an onboarding register that reads as deliberate — who ticked what on somebody's induction is part of the record — but if you expected read-only accounts to be excluded from it, change the role.

Backups are gated on settings.edit [src: app/controllers/api.php:217], which no role below admin holds [src: app/controllers/api.php:222].

Every way of ticking a task fires the webhook

Three events are offered for subscription [src: app/src/Webhook.php]: starter.created, task.completed and task.reopened. The two task events fire from every path that ticks or un-ticks a task — the browser, the bulk "tick selected" action (one task.completed per task it ticks, ob_tasks_bulk_complete() [src: app/controllers/v3.php]), the REST route and the agent tool complete_task — through one helper, ob_fire_task_event() [src: app/controllers/v3.php], and only when the task's state actually changed, the same rule the audit trail follows. Before 1.0.3 only the REST route fired them, so a manager working down the checklist on screen sent nothing to an integration.

The API and agent access

Six tools [src: app/controllers/v3.php:148]: four read — the starter list, one starter's plan, what is late, and the checklist templates — and two write, completing a task [src: app/controllers/v3.php:209] and reassigning one [src: app/controllers/v3.php:232].

Note that whats_late [src: app/controllers/v3.php:177] answers from the same derived rule the dashboard uses, so an agent and a manager cannot disagree about what is overdue.

What Onboardora does not do

It does not let an edited template rewrite a plan already in flight [src: app/src/Onboard.php:7].

It does not store a due date [src: app/src/Onboard.php:12] — move the start date and the plan moves with it.

It does not store a "late" flag [src: app/src/Onboard.php:17].

It does not overwrite who completed a task when it is ticked again [src: app/src/Onboard.php:21].

It does not silently move a task off a weekend [src: app/src/Onboard.php:69].

It does not accept an offset outside the plan window [src: app/src/Onboard.php:29].