Work order management in Cohiva Control
A work order is the unit of maintenance work, and the discipline around it decides whether your maintenance operation is controlled or chaotic. Cohiva Control treats the work order as a record that follows a defined lifecycle, enforced on the server, with a full history of how it got from raised to verified. This page explains how that works and why the control matters.
A defined lifecycle
Every work order moves through a fixed set of states: open, assigned, in progress, pending parts, completed and verified, with cancelled available as an exit. The order is not arbitrary. A job is raised as open, assigned to a person or team, worked, sometimes parked while parts arrive, completed by the technician, and verified by a supervisor before it closes. Modelling these as explicit states, rather than a single free-text status field, means the system understands where a job actually is.
The state machine is enforced on the server
The lifecycle is a state machine, and it is enforced server-side. That distinction matters. A status that is only a label in the interface can be set to anything by anyone, which is how maintenance histories end up with jobs marked complete that were never started. In Cohiva Control, an illegal transition is rejected at the API, rather than merely hidden in the screen. A work order cannot skip from open straight to verified, and it cannot move backwards into a state that does not follow from where it is. The result is that the status of a work order means something you can rely on.
Every transition is recorded
Each time a work order changes state, Cohiva Control writes an append-only history row. The history captures the change itself, so you can trace a job from the moment it was raised through assignment, work and verification. Because the history is append-only, it cannot be edited or deleted after the fact, which is what makes it useful for an audit or an incident review. When someone asks how a job was handled, the record answers honestly.
SLAs and labour cost
Work orders carry SLA targets, so you can hold maintenance to a standard. You can see which jobs are inside their target and which are at risk, and you can report on response and completion over time. Work orders also roll up labour cost, so a finished job tells you what it cost in effort, rather than only that it was done. Over many jobs, that cost data is the basis for understanding where maintenance effort actually goes.
How it fits the rest of Cohiva Control
Work orders do not sit alone. They are raised against assets in the register, generated automatically by preventive maintenance schedules, and raised by failed inspection items. Parts consumed on a work order are recorded against it for the cost rollup. Before a contractor is assigned to a work order, the contractor-compliance gate checks their documents and hard-blocks anyone who is not compliant. And because work order completions can be posted out through the open platform using signed webhooks and a typed SDK, finished work can trigger downstream processes in other systems.
Why the control matters
Maintenance lives or dies on trust in its records. If a status can be set to anything and a history can be edited, the data becomes a story rather than a fact, and reporting, audits and cost analysis all rest on sand. By enforcing the state machine on the server and keeping an append-only history, Cohiva Control makes the work order a record you can act on with confidence.
Part of the Cohiva platform
Cohiva Control is part of the Cohiva platform. Leisure operators often run it with Cohiva Complex, and finance teams connect it to Cohiva Crunch for the general ledger. Explore the platform at www.cohiva.app.