> 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/set-up-what-you-schedule/on-call-and-trust-admin.md). # On-call working patterns and Trust Admin **Who:** roster-area admin, tenant admin, or the new `trust_admin` role. **Time:** \~10 minutes end-to-end for a fresh service line (enable the Trust Admin toggle → grant perms → tick pattern cells → set the on-call flag → track the first session). > **Changed in v1.8.3.** ReSouris no longer has clinics. Everything below that used to be set on a clinic is set on the **service line**, and the "no skills required" toggle is gone entirely — see Step 1 and the note at the end. ReSouris v1.6.5 ships four feature clusters that all revolve around **on-call sessions** and **Trust Admin session tracking**: * A **third checkbox** on the AM/PM working-pattern grid — on-call sessions per weekday. * A **service line "has on-call session"** toggle that drives CP-SAT solver awareness. * A **Trust Admin surface** (new role + Upcoming/All pages + calendar LED) so operators can walk the traffic-light status of every Trust-Admin-classified session. * ~~A **clinic "no skills required"** toggle~~ — **withdrawn in v1.8.3**, along with the Readiness Check gate it existed to bypass. That gate measured whether clinics declared required skills, a field the roster engine never read; it now asks whether any service line has a position requiring a competency, which is the question the engine answers. There is nothing to opt out of. ## When to use * **On-call rota** — a worker is on-call from home Mon 17:00 → Tue 08:00; you want the solver to prefer them for the Mon AM+PM slot too (same-worker triple) OR split the shift so the on-call sub-window goes to a different qualified worker. * **Trust Admin session tracking** — an admin walks Monday morning's sessions and flips each service line's session from "Not started" → "Started but incomplete" → "Complete" as the day progresses. The roster grid shows a coloured LED per slot so operators can eyeball the whole week at a glance. * ~~**Skill-agnostic clinic**~~ — no longer a case you need to handle; see the withdrawn toggle above. ## Step 1 — Enable Trust Admin on the service line Sidebar → **Organisation** → **Services** → open the line → edit → tick **"Trust plans patient numbers for this service line"**. Save. Each service line answers for itself. Tick it when the Trust plans that line's sessions in advance; leave it clear for work that arrives unannounced — an in-patient or ED echo is unambiguously clinical work and nobody plans a count for it — and for lines that hold no patient sessions at all. > Before v1.8.3 this was a clinic-level toggle that inherited to every service line the clinic hosted. The inheritance had no defined answer when a line sat under one clinic with the toggle on and another with it off, which is one of several reasons the clinic was removed. ## Step 2 — Grant the Trust Admin perms The `trust_admin` role is documented but not seeded automatically. Sidebar → **Administration** → **System roles** → pick the role you want to hold Trust Admin (existing `tenant_admin`, or create a fresh `trust_admin` role) → grant: * `admin.trust_admin.read` — list access to the Upcoming + All pages * `admin.trust_admin.status.update` — inline status dropdown Both perms are UI-only in v1.6.5 (no `/v1/*` JSON API surface). ## Step 3 — Author on-call cells on the working pattern Sidebar → **People management** → **Working pattern templates** → edit a template. The Mon–Sun × AM/PM grid now shows a third column **On call** per weekday. Tick On call for the days the worker takes an on-call session. For per-worker patterns: sidebar → **People management** → **Staff admin** → open the worker → Working pattern tab → same three-column layout. **F3 amber warning:** if you tick AM + On call but not PM for the same day, you'll see an amber pill: "⚠ Mon: On call with no PM cover — verify handover". This is a soft signal, not a hard block — legitimate for rotas where the worker hands over PM to a colleague and is on-call from home overnight. The pattern still saves. ## Step 4 — Toggle the service line's on-call flag Sidebar → **Organisation** → **Services** → open the service line → edit → tick **"Has on-call session"**. Save. The next roster generation reads this flag + the on-call cells from step 3 and decides: * **Same-worker** — prefers a worker who holds the on-call flag AND is AM+PM-eligible for the SL. Assigns them the AM+PM+OnCall triple. * **Split-shift** — no same-worker match + the SL has `allow_split_shifts=true` (P27 feature): applies a P27 split, on-call sub-window to a different qualified worker. Emits `roster.solve.on_call_split` audit. * **Scheduling gap** — no viable coverage: auto-roster diagnostics surfaces the (SL, weekday) tuple as a gap for the operator to resolve. ## Step 5 — Track Trust Admin status Sidebar → **Trust Admin** → **Upcoming services** (default: next 14 days) or **All services** (default: last 50 rostered slots). Each row shows `(date, service line, current status, last updated)`. Row background is one of: * **Light red** — Not started * **Light amber** — Started but incomplete * **Light green** — Complete Click the status dropdown on any row + pick a new state. The form auto-submits; `trust_admin.status.updated` audit fires. Absence of a row = implicit "Not started" (the row is created on first status change). The **All sessions** page adds filters: * **Status** checkboxes (multi-select) * **Page size** selector (25 / 50 / 100 rows) ## Step 6 — Read the calendar LED Sidebar → **Operate** → **Rosters** → open the roster, then its spaces-grid view. Every slot cell whose service line has `supports_admin_status=true` renders an 8×8px LED to the left of the clinic code + worker name. LED colour follows the same traffic-light palette. Hover to see the current status text. The LED is populated by one query per grid render — no N+1, no lazy AJAX. ## ~~Skip the skills gate~~ — withdrawn in v1.8.3 There is no longer a skills gate to skip, so there is no toggle. The Readiness Check used to require that clinics declare `required_skills`, with a per-clinic **"No skills required"** opt-out for legitimately skill-agnostic work. That gate measured a field **the roster engine never read** — it could pass a tenant the engine would find no work in, and fail one it would happily roster. It now asks the question the engine answers: does any active service line have a position that requires a competency? If the readiness item is red, add a worker position with a competency to at least one active service line: Organisation → Service lines → open the line → **Positions**. ## Audit trail **Three** new audit event kinds, plus one existing kind whose payload was extended: > The list below used to say *five* and carry *six* bullets, two of which named clinic events. One of those, `clinic.supports_admin_status_toggled`, was emitted in production and documented here — but **was never registered in the audit taxonomy**, so it was never a real kind and would not have appeared as one. Both are gone with the clinic; the flag they tracked is carried in the `service_line.updated` payload. * `working_pattern.on_call_added` — one per save of a pattern/template that carries at least one on-call cell * `service_line.updated` (payload extended) — carries `has_on_call` and `supports_admin_status` on every service-line save * `trust_admin.status.updated` — one per inline status write * `roster.solve.on_call_split` — one per applied split-shift on-call recommendation Filter the audit page by these action strings to walk the Trust Admin history. ## Reversibility All schema changes additive; every UI change is additive over prior surfaces. Toggle any service-line flag back off + the associated surface simply becomes empty / muted. `service_line_admin_status` rows are recoverable from backup only if you `DROP TABLE service_line_admin_status` — retention-conditional per the standard MIG-127 / MIG-138 precedent. ## Limitations (v1.6.5) * **CP-SAT constraint is soft-priority, not hard.** The planner computes the same-worker/split/gap decisions and feeds them to the solver as preferences; the CP-SAT model doesn't yet enforce on-call as a HARD constraint. Full model-level integration lands in a v1.7 solver hardening WP. * **No on-call notification workflow.** When an on-call worker is triggered (page, SMS) v1.6.5 doesn't route the incident back into ReSouris. Deferred to a later phase. * **No TOIL / payroll accrual.** On-call hours don't yet feed a payroll subsystem. * **No Trust Admin bulk CSV import.** UI-authored flow only; CSV import is v1.7+. * **Trust Admin audit review lives at /ui/audit.** No dedicated audit dashboard — filter the standard audit page by `trust_admin.status.updated`. ## Perms cheat-sheet | Perm | Default holders | Gates | | --------------------------------- | ----------------------------- | ----------------------------------------------------------------- | | `admin.trust_admin.read` | `tenant_admin`, `trust_admin` | `/ui/trust-admin/upcoming-clinics`, `/ui/trust-admin/all-clinics` | | `admin.trust_admin.status.update` | `tenant_admin`, `trust_admin` | `POST /ui/trust-admin/status` (inline dropdown) | --- # 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/set-up-what-you-schedule/on-call-and-trust-admin.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.