# Status reference

ShiftTracker shows a status as a chip carrying an icon and a word, never colour alone. This page lists every status the interface can render, what each one means, which database value produces it, and which of 6 colour roles it uses. It also lists the 28 database values the interface has no styling for, which fall back to a plain grey chip.

<!-- GENERATED FILE — do not edit. Run `npm run docs:reference` after changing the sources named at the foot of the page. -->

## How does the platform show a status?

Every status is a chip carrying **an icon and a word**, never a colour on its own — colour alone would be invisible to anyone who cannot distinguish it, so the word is what actually tells you the state.

The colour is chosen from one of 6 roles rather than picked per status, which is why the same idea looks the same everywhere in the product:

| Colour role | What it signals |
|---|---|
| success | Something finished the way it was supposed to. |
| info | Something is set up and waiting. No action needed yet. |
| warning | Something needs a person to look at it. |
| danger | Something was called off, refused, or lost. |
| neutral | Over and filed. Deliberately the quietest treatment on screen. |
| navy | Happening right now. The only solid-filled treatment, so live work is what the eye lands on first. |

8 of the shift states also carry a purpose-drawn mark — an hourglass whose fill level tracks how far through the shift is. The marks do not animate.

## What can a shift be?

A shift's status is not simply a column that someone sets. Most of it is worked out at the moment you look, from whether anyone has booked on, whether they have booked off, and whether the start time has passed. The states a manager sets by hand win over the ones worked out for them.

| Shows as | Colour role | Status value | When the platform produces it |
|---|---|---|---|
| Completed | neutral | `completed` | Booked off, or marked complete by a manager. |
| Cancelled | danger | `cancelled` | Called off. Kept on the record rather than deleted. |
| No Show | warning | `no_show` | A manager recorded that the officer did not turn up. Stored, and it outranks anything worked out from book-on times. |
| In Progress | navy | `active` | Somebody booked on and has not booked off. |
| In Progress | navy | `in_progress` | The same live state as Active, stored on the shift rather than worked out from a book-on. Both show as In Progress. |
| Missed | warning | `missed` | The start time has passed in the organisation's own timezone and nobody booked on. Worked out on the fly, never stored. |
| Confirmed | success | `confirmed` | The shift was explicitly confirmed. It can still be removed, but removing it keeps the row rather than deleting it. |
| Scheduled | info | `scheduled` | The default. The shift is on the roster and nobody has booked on. |
| Suspended | neutral | `suspended` | Put on hold by a manager. Locked against editing and removal. |

Completed, In Progress, No Show, Cancelled and Suspended lock a shift: it cannot be edited or removed off the roster while it reads as one of those.

## What can a request or proposal be?

A request asks agencies to cover one shift; a proposal is one agency's answer naming one officer. They carry separate statuses, and both are visible on the **Requests** screen.

| Shows as | Colour role | Status value | What it means |
|---|---|---|---|
| Open | info | `Open` | Raised, and no agency has put an officer forward yet. The roster cell for it reads Awaiting agency. |
| Confirmed | success | `Confirmed` | As many officers are assigned as the request asked for. Because a request always asks for exactly one, that means one confirmed proposal. |
| Cancelled | danger | `Cancelled` | The agency fill was taken off the shift, or the roster shift behind the request was cancelled. |
| Proposed | warning | `Proposed` | At least one live proposal exists. Withdrawing the last one puts the request back to Open. |
| Withdrawn | neutral | `Withdrawn` | Taken back by whoever offered it, before it was answered. |
| Selected | neutral | `Selected` (no mapping — plain grey) | This is the proposal that was confirmed. The request stops accepting confirmations. |
| Change Requested | neutral | `Change Requested` (no mapping — plain grey) | Sent back to the agency for a different officer, time or rate. |
| Filled | success | `filled` | Every officer the request asked for has been confirmed. The roster cell reads Filled. |

Older data may still contain a `Partially Filled` request status. The platform stopped producing it — a partly staffed request stays **Open** — and existing rows were moved to Open, but the value remains in the database because Postgres cannot cleanly drop one.

## What can an offer, an application or a check call be?

Anything where somebody was asked something and has, or has not, answered.

| Shows as | Colour role | Status value | What it means |
|---|---|---|---|
| Unconfirmed | warning | `unconfirmed` | A check call whose window closed without the call being made. This is what the control room escalates. |
| Pending | warning | `pending` | Submitted and waiting for a decision. |
| Accepted | success | `accepted` | The officer or employee took the shift offered to them. |
| Declined | danger | `declined` | The officer or employee turned the offer down. |
| No Response | neutral | `no_response` | A broadcast offer reached its deadline without an answer either way. |
| Expired | neutral | `expired` | The offer or invitation lapsed before anyone acted on it. |
| Approved | success | `approved` | Accepted by whoever reviewed it. |
| Rejected | danger | `rejected` | Turned down by whoever reviewed it. |

## What can a form be?

A form template moves through the first three; a form sent to an officer moves through the rest.

| Shows as | Colour role | Status value | What it means |
|---|---|---|---|
| Downloaded | info | `downloaded` | The form reached the officer's device but has not been opened. |
| In Progress | navy | `started` | Being filled in and not yet sent. Shows as In Progress, the same as a live shift. |
| Draft | neutral | `draft` | Still being written. Not available to fill in. |
| Published | success | `published` | Live, and available to be filled in. |
| Archived | neutral | `archived` | Retired. Kept for the record; no new submissions. |
| Submitted | info | `submitted` | Filled in and sent. |
| Under Review | warning | `under_review` | Received, and being checked by someone. |

## What can a finished shift's pay be?

Arbitration is the step that decides which times a shift is actually paid on. These are the states that step leaves behind.

| Shows as | Colour role | Status value | What it means |
|---|---|---|---|
| Dropped | danger | `dropped` | Taken out of pay and out of invoicing. |
| Auto Arbitrated | success | `auto_arbitrated` | Book-on and book-off were both within 15 minutes of the scheduled times, so the hours were settled without anyone looking at them. |
| Manual Advised | warning | `manual_advised` | The worked times differ from the scheduled times by more than 15 minutes, so the shift is flagged for a person to decide. |
| Manual Complete | info | `manual_complete` | A person made that decision and the hours are settled. |
| Drop Confirmed | neutral | `drop_confirmed` | The drop was confirmed. Excluded from payroll and from client charges. |
| Paid | success | `paid` | Included in a pay run. |
| Invoiced | info | `invoiced` | Included in a client invoice. |
| Paid & Invoiced | success | `paid_and_invoiced` | Both paid and invoiced. |

## Which database values have no status styling?

A further 28 values exist in the database that the interface has no styling for. They still display: the chip falls back to plain grey and the raw value is tidied into words, so a value nobody has styled yet can never blank out or break a screen. They are listed here so that meeting one on screen is not a surprise.

| Value | Where it comes from | Shows as |
|---|---|---|
| `auto_accepted` | officer_confirmation_status = auto_accepted | Auto Accepted |
| `blocked` | onboarding_item_status = blocked | Blocked |
| `canceled` | subscription_status = canceled | Canceled |
| `denied` | cancellation_request_status = denied | Denied |
| `documents_pending` | verification_status = documents_pending | Documents Pending |
| `done` | onboarding_item_status = done | Done |
| `failed` | payment_status = failed | Failed |
| `flagged` | screening_status = flagged | Flagged |
| `gaps_pending` | screening_status = gaps_pending | Gaps Pending |
| `inactive` | employment_status = inactive | Inactive |
| `not_applicable` | onboarding_item_status = not_applicable | Not Applicable |
| `on_leave` | employment_status = on_leave | On Leave |
| `overdue` | reference_status = overdue | Overdue |
| `past_due` | subscription_status = past_due | Past Due |
| `payment_received` | verification_status = payment_received | Payment Received |
| `pending_payment` | verification_status = pending_payment | Pending Payment |
| `processing` | payment_status = processing | Processing |
| `recalled` | form_dispatch_status = recalled | Recalled |
| `received` | reference_status = received | Received |
| `references_pending` | screening_status = references_pending | References Pending |
| `refunded` | payment_status = refunded | Refunded |
| `reminded` | reference_status = reminded | Reminded |
| `requires_resubmission` | document_status = requires_resubmission; verification_status = requires_resubmission | Requires Resubmission |
| `sent` | reference_status = sent | Sent |
| `terminated` | employment_status = terminated | Terminated |
| `trialing` | subscription_status = trialing | Trialing |
| `unpaid` | subscription_status = unpaid | Unpaid |
| `uploaded` | document_status = uploaded | Uploaded |

## How is this page produced?

It is generated, not written. The labels and colour roles are read from the product's own status registry, the shift states from the function that derives them, and the database values from the schema. Regenerate it with `npm run docs:reference`; a check in the test suite fails if what is committed here has fallen behind those sources.

## What else should I read?

- [Roles and permissions](/docs/reference/permissions-reference) — who is allowed to change any of this
- [Glossary](/docs/reference/glossary) — the words used above
- [How a request becomes a rostered shift](/docs/concepts/how-a-request-becomes-a-rostered-shift) — the request statuses in order