Definition
Work Order (work order) converts alarms and faults into trackable operation and maintenance tasks, supporting order dispatch, processing, and closed loop. It can be integrated with ITSM, Event Stream, and record operation and maintenance indicators such as MTTR.
Work order life cycle
Work orders typically go through stages such as creation, assignment, processing, verification, and closure. The Device Management Platform can automatically create work orders from Event Stream alarm events or allow operations personnel to create them manually; assignment supports allocation based on strategies such as region, skill, and workload; during processing, device information, telemetry history, and Remote Diagnosis results can be associated; after verification, the work order is closed and the actual handling time is recorded for MTTR statistics. When integrated with ITSM, work orders can be synchronized to the service desk to achieve a unified operations workflow.
Integration with DMP
As a data source and execution context for work orders, the Device Management Platform provides contextual information such as device online status, health scores, historical alarms, and OTA records. Work orders can be associated with specific devices or device groups and can be created with one click from the device details page; handlers can directly initiate remote control, log collection, firmware upgrades, and other operations within the work order. The platform integrates with ITSM, EAM, CMMS, and other systems via OpenAPI, enabling automatic flow from alarms to work orders and bidirectional synchronization of operation data.
Use Cases
Work orders are suitable for industries with a large number of IoT devices, such as energy, manufacturing, transportation, and municipal services. Automatically converting fault alarms into work orders can reduce response time; preventive maintenance and inspection tasks can be managed via planned work orders; bulk device upgrades and migrations can also be tracked through work orders. Work order data supports operations KPI analysis, personnel performance evaluation, and continuous improvement, making it a key element in the closed-loop management of device operations.
A work order is a dispatchable record of the response
A work order lifts one response that needs a person responsible out of the alarm stream. It has a source, an owner, the devices involved, the handling steps, and a close result. An alarm can clear on its own. A work order does not lose its process record because the alarm recovered. Repair time is calculated only at close, and it must say which moment it runs from and which moment it runs to: from open to close, or from accept to close. If that is unstated, two teams' durations cannot be compared. An order that is not closed has only a time already waited. It cannot be written in advance as repair complete.
Dispatch should be based on the responsibility range at the time and on whether the person is on shift, not on dropping every order into a common queue for people to pick up. Self-pickup means two people handle the same order at once, or nobody handles it. Every state change leaves an operator. When syncing with an external service desk, one agreed side owns the primary state. The other side stores the counterpart's order number, so both sides cannot close and then reopen each other. When a rule should open orders automatically, the rule engine submits a "request to open" event, and the work-order module decides whether to create or to merge. The rule itself does not write the closed state directly.
Automatic open needs suppression and merge conditions
Automatic open is usable when the same device and the same fault class, if an unclosed order already exists, do not create another order. They append a count and the time of the latest occurrence on the original order. Without a merge key, a jittering alarm opens dozens of orders in a few minutes. The owner can only close them in bulk, and a real new problem is mixed in. Suppression should also recognize planned maintenance. Expected offline inside a maintenance window does not produce a fault order, or the order it produces is marked as a known impact and does not enter the response clock.
Merge cannot run across devices without a limit. A site-wide disconnect may need one site-level order to coordinate, while keeping an attachment per device, rather than generating ten thousand identical orders, and rather than keeping one order and losing the device list. The context copied at open should be the identity, the location, the latest related state, and the alarm number, not the entire historical curve pasted into the description. On permissions, the handler must already be able to reach these devices. The work order must not be a way to see data outside one's scope. Dispatch rules cite the judgment of roles and scope. They do not keep a second, contradictory list inside the work-order module.
The alarm recovers and the matching work order stays open
Alarm recovery means only that the monitored value is back inside the threshold. It does not mean the cause has been handled. Closing the work order automatically records a device that is temporarily normal after a restart as repaired, and an intermittent fault never has an owner. The recovery event should be written onto the work-order timeline and closed after a person confirms, or closed by an explicit rule when recovery has lasted a full observation period and there is no other action. Close before the observation period is up and the duration is counted short.
The opposite mistake is that the order stays pending after recovery, and nobody separates "still needs a response" from "someone forgot to close it." The queue grows, and a new urgent order is pushed behind it. The list should filter by whether it has already recovered and whether it already has an owner. When the same problem opens again, reopen the original order or create a link. Do not open a new order with no history, or the duration of one fault is cut into several stretches, each of which looks short. Close reasons should distinguish repaired, duplicate, false alarm, and will not handle. Counting every close as repaired lets false alarms into the quality statistics. A close with no reason filled in should be rejected. At least one required result category should remain.
Before closing, check whether the timeline still has an unfinished remote action. If an upgrade or a control action is unconfirmed, the result cannot be set to repaired. Waiting for parts and waiting for a window should use a separate suspended state. Whether suspended time counts toward the response limit has to be agreed in advance in the contract. The person closing the order cannot decide it in a note. A reopen must return to a clear handling state and notify the current owner, so the order is not open in the system with nobody notified.