> For the complete documentation index, see [llms.txt](https://help.resouris.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.resouris.com/manage-people/worker-lifecycle.md). # Worker lifecycle **Who:** roster-area admin, tenant admin. **Time:** \~15 minutes end-to-end (grant perms → archive a worker → reactivate → author a pattern change). ReSouris v1.6.6 ships two coupled feature clusters that together make **worker lifecycle** a first-class citizen: * **Effective-dated working-pattern assignments** — author a pattern change ("this worker moves from 4 days/week to 3 days/week starting April 1") without losing the historical pattern. Multi-week rotations honoured per assignment (F9 cycle-anchor). * **Archive + reactivate** — mark a worker as departed (with an end reason + date + notes), then bring them back on the exact same worker record so every prior accreditation, competency, and training record persists intact (F1 lock). ## When to use * **Pattern change on a fixed future date** — worker's contract changes on 2026-04-01. Author a new assignment effective from that date; the prior assignment truncates automatically. * **Multi-week rotations** — worker moves onto a 2-week alternating pattern. Enter both weeks with the same `effective_from`; the solver's cycle math picks the correct week per date. * **Worker leaves** — archive from the staff list. Record the end date + reason (from the F5 closed set) + optional notes. Their competencies + training remain visible on the worker record. * **Worker returns** — reactivate from the staff-edit header (only visible when the worker has a closed spell). A new employment spell opens on the **existing** worker record. All prior history is preserved. * **F1 audit trail** — the Employment History tab shows the full spell + pattern-change timeline for any worker. ## Step 1 — Grant the perms Sidebar → **Administration** → **System roles** → pick the role you want to hold worker-lifecycle actions (existing `tenant_admin` or `roster_area_admin`) → grant: * `admin.staff.archive` — Archive worker action on the staff list. * `admin.staff.reactivate` — Reactivate worker action on the staff-edit page. Both perms are UI-only in v1.6.6 (no `/v1/*` JSON API surface). ## Step 2 — Author an effective-dated pattern change Sidebar → **People management** → **Staff admin** → open the worker → **Working pattern** tab. Above the week grid you'll see a **"Pattern-change history"** card listing every prior assignment: `(effective_from, effective_to, cycle_length, week_index)`. Newest-first. Fill the two new date fields at the top of the form: * **Effective from** (required) — the date the new pattern starts to apply. Defaults to today. * **Effective to** (optional) — leave blank for open-ended, or set a fixed end date for time-boxed changes. Save. Behind the scenes: 1. The previously-open assignment(s) on the same spell get truncated to `effective_to = effective_from - 1`. 2. A new assignment opens for each week in your rotation. 3. `staff_working_pattern.assignment_changed` audit event fires. ## Step 3 — Archive a worker Sidebar → **People management** → **Staff admin** → find the worker → click `⋯` action menu → **"Archive worker…"**. The modal collects: * **End date** (required) — the worker's last day. Must be on or after the current spell's start. * **End reason** (required) — pick from the closed set: Resigned / Retired / Dismissed / Contract ended / Deceased / Other. * **Notes** (optional) — free text appended to the spell notes column. Submit. One transaction: 1. Close the open employment spell with your date + reason + notes. 2. Truncate every open working-pattern assignment to that end date. 3. Flip the worker's state to "Archived" (shows as an "Archived" chip on the staff list). 4. Emit `staff.archived` audit event. **What stays intact after archive:** every accreditation, competency, training row, appraisal, logbook entry. They're all tied to the worker record, not the employment spell. ## Step 4 — Reactivate a worker Sidebar → **People management** → **Staff admin** → open the archived worker → **"Reactivate worker…"** button (top of page, only visible when the latest spell is closed). The modal collects: * **Start date** (required) — defaults to one day after the prior spell's end. Cannot be on-or-before that date. * **Notes** (optional) — free text on the new spell. Submit. One transaction: 1. Open a new employment spell on the **same worker record** (F1 lock). 2. Flip the worker's state back to "Active". 3. Emit `staff.reactivated` audit event. 4. Redirect to the **Working pattern** tab so you can author a pattern for the new spell. The Employment History tab now shows **two** spells: the historical (closed with the archive reason) and the new open one. Same worker id, complete audit trail. ## Step 5 — Review the Employment History tab Sidebar → **People management** → **Staff admin** → open the worker → its employment-history tab. Read-only surface showing every spell chronologically (newest-first). Current spell auto-opens. Each spell shows: * Date range: `started_on → ended_on` (or "open" if current). * End reason (when closed). * Notes. * Nested table of every working-pattern assignment authored during that spell's window. Use this as the F1 audit-trail view: proof that the returned worker is genuinely the same record, with the full history behind them. ## Solver behaviour The auto-roster planner honours the F8 lock: a worker with no employment spell covering a specific slot date is not considered a candidate for that slot. This composes with the F9 pattern lookup so: * A worker archived on 2026-06-30 is invisible to the solver for any slot on 2026-07-01 or later, until they're reactivated. * A worker with a pattern change from 2026-04-01 sees the new pattern applied from that date forward; historical dates use the prior pattern. **Diagnostic surface:** Sidebar → **Scheduling** → **Auto-roster diagnostics**. The "Workers skipped for out-of-spell dates" card shows recent auto-roster runs where any workers were excluded, with per-worker date lists. If a worker appears here unexpectedly, reactivate them via Step 4. ## Setup Checklist behaviour The `Staff records complete` probe now reads: > **Every currently-employed active staff must hold a working pattern AND at least one competency. Workers archived via the staff-list Archive action are excluded from this check — reactivate them if they need to be rosterable again.** Archived workers stay off the checklist's "missing something" list. Only currently-employed workers with gaps get flagged. ## Common mistakes * **Not granting the perms first** — the Archive and Reactivate buttons will be hidden until you grant them via Roles. If you can't see the actions, check your role's permissions. * **Setting `effective_from` before the spell's `started_on`** — the DB trigger refuses ("assignment\_outside\_spell" error). Extend the spell first if needed, or pick a later effective date. * **Trying to archive twice** — a worker with no open spell has nothing to close. The handler surfaces "no open employment spell" — check the Employment History tab to see the current state. * **Reactivate start date on-or-before the prior end date** — refused by the gist EXCLUDE constraint. Pick a date strictly after the prior `ended_on`. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.resouris.com/manage-people/worker-lifecycle.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.