Work orders

The unit of maintenance work - creating, assigning, scheduling, and completing work orders, and the views that keep the queue moving.

A work order is one job: what needs doing, where, by whom, by when, and - once complete - what it took. If it took someone's time, it should be a work order; that habit is what makes every downstream number trustworthy.

Creating a work order

From Work Orders → New, from an asset's page, from a work request conversion, or automatically from a PM schedule.

The essentials:

• Title and description - what's wrong / what to do
• Association - what the work is on: any mix of asset(s), location(s) for non-asset work ("paint room 114"), system(s) to cover a whole bucket of related assets at once (a "Refrigeration - Monthly Inspection" against the Refrigeration system inspects every asset under it - complete coverage, which is exactly what compliance audits want to see), or infrastructure feature(s) for linear assets (the watermain segment, the culvert). A work order needs at least one association to be useful.
• Priority - Low, Medium, High, or Urgent; priority drives queue order
• Work category - feeds reporting by trade/type of work
• Assignment - one or more staff members, or a vendor for contracted work
• Start date / due date - when it should happen

Work orders generated by a PM schedule carry a PM type badge; everything else is demand work. At completion, a cost category (Repair, PM, Operation, Replacement, Decommission, or Other) labels how the costs post to the asset.

Beyond the essentials, a work order can carry:

• Task checklists - discrete steps ticked off as the job progresses
• Safety requirements and procedures - with an acknowledgement checkbox, so "read the lockout procedure" leaves a record
• Parts used - lines that deduct from parts inventory and post their cost
• Meter readings - a reading recorded on the work order writes back to the asset's current meter reading (only when it is higher than the stored value, so out-of-order entries can't roll a meter backwards)
• Attachments (photos of the problem) and forms

Working the queue: five views

Filters cover status, priority, PM vs. demand type, site, building, location, assignee, an "assigned to me" shortcut, and infrastructure scope - plus text search. Column visibility and order are configurable per table and persist between visits.

Organizations running both facilities and infrastructure get a Facilities / Infrastructure switcher above the filters. Facilities is the familiar panel (site, building, location). Switching to Infrastructure narrows the queue to work orders bound to an infrastructure feature and swaps in the infrastructure filters - network, feature class, feature type, and condition band - the same panel infrastructure-only teams already see. The choice persists per device, and status, priority, assignee, and search apply on both sides.

In List view, a small gallery icon next to the title marks a work order that carries photos, with a count when there is more than one - so you can spot the jobs with visual evidence without opening each one.

Two views do real work on drag:

• Calendar - drag a work order from the unscheduled sidebar onto a technician's lane to assign that technician and set the due date in one motion; dragging between days in month view rewrites the due date.
• Kanban - dragging a card into Completed or Cancelled opens the completion dialog, so a drag can't skip the close-out actuals.

In List view, multi-select supports bulk delete (Administrators only). Export is available to Managers and above.

Status flow

Work orders move New → In Progress → Completed, with On Hold and Cancelled as the side exits. Two rules keep the data honest:

1. Completion asks for actuals - hours worked and costs incurred. Thirty seconds at close-out is what makes cost history real.
2. Completed work orders post costs to the asset automatically - labour, parts, and expenses land in the asset's cost history and roll up through buildings and sites. See Expenses & costs for the mechanics.

Notes and collaboration

The internal narrative lives in two places: completion notes on the work order ("found the actual fault, parts ordered"), and - for work orders converted from a work request - the requester conversation, the live two-way thread with the person who reported the problem, continued from the request. The technician can ask "is the noise constant or on startup?" mid-job without leaving the work order. Completion notes are internal; the conversation is what the requester sees.

A separate comment thread on work orders exists for integrations - it is available through the REST API and MCP tools (work_order_comments), not in the app's work order screen.

Exporting

Export (Manager and above) offers three formats:

• Excel analytics report - work order data with analysis sheets
• PDF management report - KPIs, charts, backlog, and team & site performance
• CSV - a flat export for spreadsheets and imports

Exports respect your site, assignee, and other filters but span all statuses regardless of the current status filter - a report filtered to "In Progress" still exports the completed history behind it.

Sharing outside the team

A work order can be shared via a secure link for someone without an account - typically a contractor who needs the details for that one job. Each link has an expiry (24 hours to 90 days, or never) and is view-only by default; ticking allow completion when creating the link lets the recipient update progress and complete the job. Links can be revoked at any time.

Completing well

A well-closed work order has: actual hours, costs (or parts consumed), a photo if anything visual changed, and the form filled if one was attached. That record is your warranty evidence, your budget justification, and your technician's institutional memory - all in one place.

Programmatic access

work_orders:read / work_orders:write scopes on the REST API; list_work_orders, create_work_order, update_work_order and comment tools via MCP.