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. Features are multi-select like the rest: pick every feature one job covers - a round of hydrant flushing is one work order with one completion, and its cost divides across the features when you close it.
• Priority - Low, Medium, High, or Urgent; priority drives queue order
• Work category - feeds reporting by trade/type of work. In an organization running both Facilities and Infrastructure, each category is filed under Settings → Categories → Work Categories as Facilities, Infrastructure or Shared: work on a network feature offers infrastructure and shared categories, anything else offers facilities and shared ones
• 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. Filters and search stay set for the rest of your browser session, and the list remembers its page, so opening a work order and going back returns you to where you were. Column visibility and order are configurable per table and persist between visits.

Organizations running both facilities and infrastructure get a Facilities / Infrastructure / Shared switch at the top of the page. The page opens on Shared, which lists every work order with the facilities filter panel. Facilities or Infrastructure narrows the queue to that workspace's work orders and swaps the filter panel to match: Facilities keeps the familiar site, building and location filters, while Infrastructure brings network, feature class, feature type, and condition band - the same panel infrastructure-only teams already see. The Map view follows the switcher and appears on the Infrastructure side only, since facility work orders carry no coordinates. The choice persists per device, and status, priority, assignee, and search apply on both sides. A work order covering features in more than one network is listed under every network it touches, not just the one its first feature belongs to - so a street reconstruction spanning the watermain and the sidewalk shows up whichever of the two you filter by. Feature type and condition band still read the work order's first feature. The work order's own summary lists every feature it covers and every network they span, and the Network scoper on the form takes several networks at once - so one work order can cover a hydrant and the main it sits on without the picker hiding one of them.

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. The month view also shows completed work orders, greyed with a check on the day they closed - they can't be dragged, and clicking one opens it. The week view places every assigned work order in its technician's lane by due date (completed ones by completion date). It spans two weeks at a time - scroll sideways to reach the second week, and the arrows step the window forward or back one week - while the technician rows scroll under a fixed day header. Dragging a due-date placement to another cell turns it into a real schedule entry.
• 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.

The completion screen lists the photos already on the work order under Attachments. Click one to open it full size, then step through the rest with the arrow buttons or the left and right arrow keys.

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.