Work request settings

This screen configures the front door: where a work request can arrive from, what it can be classified as, and what triage is told once it arrives. Open it from Administration → Work requests.

If you don’t see this in your navigation, your administrator can switch the module on under Administration → Modules, or it may not be included in your plan.

The stat strip counts the sources and categories you have. Below it are three sections. Who can change this. Sources and categories are edited by people whose role includes Add configuration entries and Edit configuration entries. Without them the screen is read-only.

Request intake

Where requests come from, each shown with how many requests arrived that way. The defaults are API, Email, IoT alert, Mobile app, QR code scan, Rule, Telegram and Web portal. Each source is tagged:

Tag	Meaning
self service	A person outside maintenance typed it in themselves — the portal, a QR code, the mobile app
automated	A sensor, a rule or an integration raised it, with no person involved

Click a source to edit it.

Field	What it means	Notes
Name	How the request reached you — “Phone call”, “Operator portal”, “Sensor alert”	Required
Raised by the requester	Somebody outside maintenance logged it themselves, rather than phoning it through	Shows as self service. Worth measuring: it tells you whether the portal is being used
Raised by a system	A sensor, a rule or an integration raised it	Shows as automated
Active	Whether the source is offered	Turning it off keeps every request already logged against it

Requests can also arrive by email. The address they arrive at, and the record of everything that came through it, are under Notifications → Mail arriving — see notifications.

Request categories

What a report is classified as, and what triage should suggest for each kind. The defaults are Equipment not running, General request, Leak and Noise or vibration. Each row shows the category’s suggested priority and how many requests have been filed under it. Add a category opens a new one; click a category to edit it.

Field	What it means	Notes
Name	What a requester picks from	Required. Write it in their words — “Water leaking”, not “Hydraulic loss of containment”
Inside	The category above this one	Leave empty for a top-level choice. Nesting lets a long list stay short on the request form
Default work order priority	The priority suggested for requests filed here	Options come from the priority ladder
Default work order type	The kind of job these requests usually become	Options come from work order types
Active	Whether the category is offered on the request form	Turning it off keeps requests already filed under it

A category’s defaults are a suggestion rather than a rule. Whoever triages the request can still choose a different priority or type when converting it into a job.

What “how bad” is worth

The request form asks one question about urgency, with four answers: critical, high, medium and low. This panel shows what each answer suggests on your own priority ladder — for example, critical → Critical, 1h — together with that priority’s response time. The panel is read-only. A planner sets the job’s priority when the request becomes work, and the ladder itself is edited on work order settings. On a ladder with fewer than four rungs, two answers share the nearest rung.

If no priorities are configured, a report suggests nothing and a request converted into a job arrives without a priority. Build the ladder under work order settings first.

Setting up

Configuration

Request intake

Request categories

What “how bad” is worth