# Work requests

> Intake and triage - how reported problems become scheduled work, with auto-assignment, approval flows, and linking to existing work orders.

Source: https://app.assetlab.ca/docs/cmms/work-requests

A work request is a reported problem that hasn't been vetted yet. Keeping requests separate from [work orders](/docs/cmms/work-orders) protects the queue: technicians see committed work, while triage happens upstream.

## Where requests come from

- The **[requester portal](/docs/cmms/requester-portal)** - occupants, tenants, user groups
- **[QR scans](/docs/asset-management/qr-codes)** - a scan on a broken asset opens a pre-tagged request form
- **[Email intake](/docs/cmms/email-intake)** - a dedicated address that turns incoming email into requests, no login required
- **Staff** - anyone can log a request when they spot something that isn't today's job

A request needs only a description and a place - photos help, and requesters are asked for a location so triage doesn't have to guess.

## Triage

Requests land in **Work Requests** for Staff and Managers to review:

1. **Validate** - real issue? enough information? If not, ask - every request carries a [live conversation](#live-conversations) with the person who reported it.
2. **Approve and convert** - conversion creates a work order carrying over the description, photos, location/asset, and the requester link.
3. **Or link to existing work** - the same leak gets reported by five people. **Link & Approve** attaches the request to an existing open work order instead of creating a duplicate; the requester stays connected to the job that's already dispatched.
4. **Or decline** - with a reason the requester sees. Declining honestly beats a request rotting in "open".

Requesters with a [portal](/docs/cmms/requester-portal) account see their request's status change live as it moves - received, approved/declined, converted. Status changes don't send email on their own; when you want the requester notified, post a [conversation message](#live-conversations) - those are emailed.

> [!note] By default any staff member can approve requests. The **require manager approval** toggle under **Settings → Work Orders** restricts approval to Managers and above.

## Live conversations

Every work request carries a **two-way message thread** between the requester and staff - a real conversation, updating live, not a one-shot rejection comment.

- **Ask instead of guessing.** "Which door exactly?" beats declining for vagueness or dispatching to the wrong one. The requester answers from their [portal](/docs/cmms/requester-portal); staff reply from the request or the work order.
- **The thread follows the work.** When a request converts, the conversation continues on the [work order](/docs/cmms/work-orders) - pre-approval clarifications and during-work coordination live in one place, and the technician arrives with the full exchange.
- **Nobody has to poll.** New messages trigger email notifications, and unread replies are badged in both the portal and the app.
- **Privacy holds.** A requester sees only their own threads; staff see the organization's.

> [!tip] Triage in the thread, decide in the status. Use the conversation for questions and context; use approve/decline/convert for the decision - requesters get both, and the record stays auditable.

## Auto-assignment and auto-approval

One toggle under **Settings → Work Orders** - **auto-assignment** - drives both behaviors:

- **Auto-assignment** matches incoming requests to [user groups](/docs/manage/roles-and-permissions) by site and work category (a specialist group for the matching category first, falling back to a generalist group with no category restriction) so the right people see them immediately.
- **Auto-approval** rides on the same toggle, gated by priority. **Low**-priority requests auto-approve whenever auto-assignment is on. Higher priorities auto-approve only when a user group matching the request's site (and category, with the generalist fallback) actually has members - a request nobody would be routed to always waits for a human.

Start manual, observe the patterns, then automate the streams that never get declined anyway.

## Metrics worth watching

On the [dashboard](/docs/asset-management/dashboards):

- **Request→conversion time** - how long triage takes; the requester-experience number
- **Decline rate by source** - high declines from one building usually means a communication problem, not a reporter problem
- **Volume by category** - recurring request types are PM candidates: five "door sticks" requests are one [PM schedule](/docs/cmms/preventive-maintenance) in disguise