# How a request becomes a rostered shift

A request asks agencies to cover one shift. An agency replies with a proposal naming one of its own officers and an hourly rate. You confirm one proposal, that confirmation is recorded as an assignment, and the roster cell the request came from then reads as filled and names the officer.

## What are the stages?

1. **Request** — one site, one date, one start and end time, for exactly one officer. Asking for more is refused outright: *Quantity must be exactly 1. To request multiple officers, create separate requests.* Two guards on one night is two requests.
2. **Share** — a request reaches an agency only once it has been shared with that agency, either by picking agencies as you raise it or by sharing it afterwards. An agency's **Requests** screen lists the requests shared with its agency and nothing else.
3. **Proposal** — the agency puts an officer forward at an hourly rate. It can only propose its own officers, and only officers who have already accepted their login invite. A request can hold several proposals: one per officer put forward, across every agency it was shared with.
4. **Assignment** — you confirm one proposal. That proposal becomes **Selected**, the assignment records which officer and which agency, and the request stops accepting confirmations.
5. **Roster** — the cell now reads as filled and shows the officer's name.

Confirming also copies the shift into the officer's own roster, which is what puts it in their portal — the portal reads that roster, not the assignment. If the agency has not rostered that officer, the assignment still stands but the shift never reaches them.

## What do the request statuses mean?

| Status | What it means |
|---|---|
| Open | Raised, and no agency has put an officer forward yet. Every new request starts here. |
| Proposed | At least one live proposal exists. The first proposal moves the request from Open to Proposed, and withdrawing the last one moves it back to Open. |
| Confirmed | As many officers are assigned as the request asked for. Because a request always asks for one, that means one confirmed proposal. |
| Cancelled | The agency fill was taken off the shift, or the roster shift behind it was cancelled. |

![The organisation's Requests screen listing five requests for one week, each with its status beside the site name: Confirmed, Open, Cancelled, Proposed, and a second Open. Every row shows the date, the hours, how many officers were asked for, and the site's postcode.](/docs/img/requests-list-statuses.png)

So a request does not go straight from Open to Confirmed. It passes through **Proposed** for as long as offers are on the table and none has been confirmed.

Older data may contain a `Partially Filled` status, but the platform no longer produces it and existing rows were migrated to **Open**. The value still exists in the database because Postgres cannot cleanly drop one.

## Where do I see each stage?

Requests and their proposals live on the **Requests** screen, which organisations and agencies both have. The agency sees the same requests under **Available Requests**, with a **Propose** action on the ones still open and a **Proposal Sent** badge on any it has already answered.

![The same five requests seen by the agency. The heading reads Available Requests; the two Open rows carry a green Propose button, and the Proposed row carries an amber Proposal Sent badge instead.](/docs/img/agency-requests-inbox.png)

The roster says the same thing on the cell the request was raised from: **Awaiting agency** while the request is Open, **Proposed** once an officer has been put forward, and **Filled** once one is confirmed. The request form's slot picker prints those same three words, so the picker and the roster cannot describe one slot two different ways.

![The Date & Time step of the new-request form on Pick existing slot, showing the roster week as a grid. Cells already covered read SCHEDULED with the officer's name and cannot be picked; Wednesday and Saturday each offer a pickable 07:00–19:00 chip, and one cell reads Awaiting agency.](/docs/img/request-slot-picker.png)

Where the shift lands depends on what it was raised against. A request raised from a pattern seat produces a shift carrying that pattern, so it sits in that pattern's row. A request raised through **New ad-hoc slot** produces a shift carrying no pattern at all, so on **Week** + **Patterns** it drops into the single row beneath the pattern rows, labelled **Ad-hoc** with **Unscheduled — no pattern** under it.

## Related

- [Patterns, seats and ad-hoc shifts](/docs/concepts/patterns-seats-and-ad-hoc-shifts)
- [Organisation, agency, client — who is who](/docs/concepts/organisation-agency-client)