Management Dashboard — The Lifecycle, End to End

Every job — a survey, a set of remedial works, or both together — moves through the same spine: one line that shows exactly where it is, what happens next, and (honestly) how it got there if the tidy path wasn't followed. Tiered — Basics for reading the spine day to day, Deep dive for the "flexibility with caveats" gates and what each chip means, Technical for how it's derived.

Basics — reading a case's position

Open any work order or works order and you'll see the case lifecycle rail — every stage, in order, with each one marked:

✅ done — reached, with a date where one is recorded.
🔵 current — where the case is right now.
⚪ upcoming — not reached yet.
⊖ skipped — doesn't apply to this case (see survey-only / works-only below) — struck through, never shown as if it happened.

The full spine, in order:

Raised → Survey Scheduled → Surveyed → Summary Provided → Works Scheduled → Works Complete → Verified → Closed

Alongside the rail, the management dashboard always shows one Next step button — the single action that moves the case forward from wherever it currently sits (send the resident summary, schedule a verification re-survey, close the case, and so on). There's no separate place to hunt for "what do I do now" — it's always the same button, in the same place, for every case.

The mobile capture app shows the same rail, read-only. A surveyor or field operative sees exactly where their job sits in the process — on the sealed survey record and on the works job detail — but the caveat actions below (marking a summary as sent externally, verifying by attestation, closing a case) are dashboard/coordinator actions only, never available from the field app. The app answers "where is this job", not "what do I decide".

Deep dive — flexibility with caveats

Real housing management doesn't always fit the tidy path — a summary gets posted rather than sent through the platform, a supervisor signs off works on a site visit rather than booking a full re-survey, a photo genuinely can't be taken. Rather than blocking those situations outright (which just pushes them off-system, into a spreadsheet nobody sees) or pretending they didn't happen, every gate below has a primary, evidence-rich path that advances the case automatically, and an explicit, weaker, honestly-labelled alternative that a coordinator can choose instead. The alternative never looks the same as the real thing: it always requires a person, usually a reason, is logged in the audit trail, and shows a visible chip on the record for as long as that record exists.

Stage gate	Primary path (automatic)	Caveat path (manual, always labelled)
Summary Provided	The written summary is sent to the resident through the platform.	Mark summary as provided externally — a coordinator records that it was delivered another way (printed, posted, emailed directly), with an optional note on how. Chip: Summary Provided Externally.
Works Complete — photo	At least one fingerprinted after-photo is captured.	If your organisation's policy makes photos optional for works completion, a completion note is required instead — never a wholly empty record. Chip: Notes Only — No Photo Evidence.
Works Complete — location	The field app captures a GPS fix at completion.	A coordinator completes the job on the operative's behalf from the dashboard (no one was on site to complete it in person) — no location is captured or claimed. Chip: No Presence Data.
Verified	A follow-up re-survey is raised against the same works order and confirms the hazard is resolved.	Verify by attestation — a coordinator records that they inspected and accepted the completed works without a fresh re-survey, with a mandatory reason. Chip: Verified By Attestation — No Re-Survey.
Closed	Automatically eligible once a case is Verified (or, for a survey that needed no works, once its summary is provided).	Close case — a coordinator closes with a reason: Verified, No works needed, or Closed without verification. The last of these always shows amber, never green — it is never dressed up as a verified closure.

A few things that are true everywhere on the spine:

Nothing is ever silently substituted. A caveat chip is always visible on the record, in reports, and in the case history — anyone reviewing the file later sees exactly which path was taken.
Statutory clocks are untouched by any of this. Awaab's Law deadlines are computed from their own events and keep running regardless of which path a case took. A caveat can never make a compliance breach look resolved.
Cancelling a job (at any stage, with a reason) is a separate, always-available action — it lands on Closed too, but is tracked distinctly from a genuine closure (see the buckets below).

Survey-only and works-only cases

Not every case runs the full eight stages:

Survey-only. A sealed survey that finds no hazard — or whose summary is enough on its own — skips straight from Summary Provided to Closed (reason: No works needed). The works stages show as skipped, not upcoming: they were never going to happen for this case.
Works-only. A works order raised directly, with no source survey (for a tenant-reported fix, planned maintenance, or making a property safe), starts at Works Scheduled — the first four stages are structurally skipped, and the record carries its own honest No Source Survey (Direct Works) chip for its whole life, separate from the caveat chips above.
Works raised from a survey, viewed on its own record. A works order's own detail page reports its position from Works Scheduled onward — the earlier stages belong to the survey that raised it, not to the works record itself.

The buckets, briefly

The work orders list groups cases into Not Started / Requires Works / Completed / Closed / Cancelled. Closed means a case concluded and was signed off (via any of the paths in the table above); Cancelled means the job itself was called off. They're kept deliberately distinct — "concluded" and "abandoned" aren't the same story, even though both stop the case from needing further action.

Technical — how it's computed

The stage is derived, not stored — a pure function (caseStage(), packages/shared/src/lifecycle.ts) reads a case's existing fields (status, works state, stage timestamps, and the three caveat markers below) every time it's displayed. There is no separate "current stage" field that can drift out of sync with reality.
The three caveat markers are summaryProvidedExternallyAt/By/Note, attestation ({by, at, reason}), and closedAt/By/Reason — each write-once, each set by its own coordinator-only, audit-logged action (markSummaryProvidedExternally, verifyWorksByAttestation, closeCase). None of them can be set by a direct client write — every path goes through a server-side callable that checks the caller's role and records the audit event.
For a case where the works happened on a separate works-order record (works raised from a survey), the survey's own stage view cross-references the furthest-progressed, non-cancelled works order linked to it — so the case's position always agrees whichever record you're looking at it from.
The capture app renders the identical caseStage() output through its own read-only presentational component — same facts, same chip vocabulary, redrawn in the app's own visual style. Portal and app can never disagree about a case's position, because both read the same derivation.

Next: Work orders & the Awaab timeline, or back to the help index.