--- title: "Work Requests" description: "A work request is what your floor submits when something looks wrong: \"Press won't start\", \"Forklift makes a noise\", \"Air conditioning is leaking water\"." --- > Documentation Index > Fetch the complete documentation index at: https://docs.beelocity.com/llms.txt > Use this file to discover all available pages before exploring further. # Work Requests A **work request** is what your floor submits when something looks wrong: "Press won't start", "Forklift makes a noise", "Air conditioning is leaking water". It's the inbox that feeds the maintenance work-order pipeline. A request is _not yet_ maintenance work — it's a candidate for maintenance work, awaiting a planner's review. ## Submitting a request The mobile-friendly submit form captures: - The asset (if known) — the QR scan flow on the asset's sticker pre-fills it. - The functional location (if no specific asset) — useful when the user can't identify the exact unit. - A problem code from the catalog — filtered to codes relevant to the asset class. - An optional severity override — H (high), M (medium) or L (low). Use when your intuition disagrees with the catalog default. - Free-text details of what looks wrong. The field is labelled **Details**, because it holds a description of the problem rather than the designation of an item. - Optional attachments — photo, short video. Submitting computes: - An auto-generated request number (e.g., `WR-2026-0042`). - A **response tier** — `IMMEDIATE` / `URGENT` / `STANDARD` / `LOW` — computed from asset criticality × problem severity. The grid column reads **Response tier**. - A **response due** date — the operating-calendar moment by which a planner must accept or reject the request, counted on the operating calendar rather than the clock. The new request lands in the planner's inbox as `NEW`. ## Response tiers The tier sets the response-time target: - **IMMEDIATE** — A-critical asset with H severity. First response measured in minutes. - **URGENT** — A-critical with M severity, or B-critical with H severity. First response within roughly 4 operating hours. - **STANDARD** — B-critical with M severity, or C-critical with H or M severity. First response within about a day of operating time. - **LOW** — C-critical with L severity. Re-reviewed periodically. Your tier matrix is configurable — different orgs have different tolerance for delay. The triage queue narrows on its **filter button**: **Status**, **Response tier**, **Asset**, **Problem code**, **Functional location**, **Active**, or a **Submitted** / **Response due** date window — `Status = New`, `Response tier = Immediate` is what a planner opens first ([Working with lists](../getting-started/working-with-lists.html#narrowing-the-list)). ## Triage states A planner reviews each request and moves it through one of these states: - **NEW** — Just submitted; awaiting review. - **ACCEPTED** — Planner has seen it and committed to acting. Not yet a work order — the parts, the team and the schedule still need sorting. - **DEFERRED** — Will deal with later; a **Defer reason** and a **Re-review date** are both required. Deferred requests come back to `NEW` on their re-review date. The bulk action calls this outcome **Defer** too — the button, the field and the status are one word. - **CONVERTED** — Turned into a maintenance work order. Terminal — once converted, the request is read-only and all edits move to the work order. The request's **Converted to work order** field links to it. - **REJECTED** — Won't be done; reason required. Terminal. A planner can bulk-triage several requests together (the same asset reported by three operators in the same shift) — accepting, deferring, or rejecting them in one pass. The road from New to Converted runs along the bottom of the request's page. Each step shows whether it has been reached, which one the request is on now, and what is still ahead; hover a step you have already passed to see when it was reached and who moved it. Deferring and rejecting ask for what they need first — the deferral for the reason and the re-review date, the rejection for the reason — and converting opens the dialog below. A request a planner converted straight from the inbox shows Accepted as stepped over rather than missing, so the road still reads as one journey. ## Conversion to a work order Moving the request to **Converted** opens a dialog that inherits the request's asset, functional location, problem code, severity and team default. One request can spawn several work orders — a repair plus a follow-up inspection, say — so the dialog takes a row per order, and each row may override the flavour (usually `CORRECTIVE` or `BREAKDOWN`), the severity, the priority, the assigned team and the details. A field left empty inherits from the request and the asset. **Release immediately** pushes every new order straight past draft: the parts are set aside, the expected cost is frozen and the machine is booked out of production in one step. Leave it unticked to review each order in draft first. The generated work order carries `source = WORK_REQUEST` and points back at the request, so the audit trail is preserved. ## Duplicate suppression When you start a new request for an asset that already has an open request (`NEW`/`ACCEPTED`/`DEFERRED`) for the same problem code, the UI warns you and links to the existing request rather than blocking — sometimes the second submitter has useful new context to add, sometimes they didn't see the first request and would happily defer to it. Source: https://docs.beelocity.com/en/maintenance/work-requests/index.mdx