The work order app fields that hold up.
A work order app has one job days, months, or years after the work is done: prove what happened. Not just that someone showed up, but what they found, what they used, and who signed off. That is the real test of a work order app, and it is the same test that decides whether the broader category of field service apps actually earns its keep in the field instead of just looking good in a demo.
This page is about the plumbing underneath any work order app: the fields a work order needs to hold up months later, and the status states that need to move in a fixed, provable order rather than however a spreadsheet cell happens to get typed.
See what a work order needs to captureThe short version
Nine fields, and a status that can't be edited into lying.
A work order app needs a work order ID, the asset or location, who requested it and when, what was asked for, who it is assigned to, a timestamped status history, the labor and parts used, and a completed, signed-off record at the end. Status should be a fixed set of states, not free text, so "all open work orders" means the same thing every time someone runs that report. The rest of this page is why, with a real example of a system that enforces both.
The auditable fields
What a work order needs to capture.
Every trade adds its own fields on top, but the base record that a maintenance work order app, a punch list, and a field inspection all share looks the same:
- A unique work order ID that never gets reused
- The asset, unit, or location the work applies to
- Who requested it, and the date and time it was opened
- A description of what was actually asked for
- Priority or urgency
- Who it's assigned to
- A status history with a timestamp on every change
- Labor hours and parts or materials used
- Completion notes and a sign-off, with who and when
Some trades don't get to decide this list for themselves. HVAC service on equipment holding 50 pounds or more of ozone-depleting refrigerant falls under EPA Section 608 recordkeeping rules: the owner has to be able to produce the service date, the type of service performed, and the quantity of refrigerant added, and technicians have to invoice that amount directly. See the EPA's recordkeeping requirements . If you're scoping an HVAC work order app, those fields aren't optional extras, they're the minimum an owner needs on file if a technician is ever asked to prove the work.
Try it
Does your current work order capture this?
Check off what your work orders already record, on paper, in a spreadsheet, or in whatever app you use now.
0 of 9 · Start here — none of this is captured consistently yet.
The priority field
How urgent is this work order?
Priority is the field most likely to be typed in by feel, and it's the one an audit or an angry customer will ask about first: why did this sit for three days? A short, consistent set of rules for setting it beats leaving it to whoever opens the work order.
Try it
What priority should this work order get?
Answer what applies. This is a starting point, not a policy, the right thresholds depend on your industry and your contracts.
Suggested priority
Answer the questions above to see a suggested priority.
Status, not free text
How work order status actually works in the field.
The most common way a work order app fails an audit isn't a missing field, it's a status field that's just a text box someone types into. A mature system treats status as a small, fixed set of states with rules about which transitions are legal. IBM's Maximo, a widely used enterprise CMMS, is a real example of the shape:
| Status | What it means | What moves it forward |
|---|---|---|
| Waiting for approval | Submitted. The default status of a brand new work order. | Moves to Approved once someone signs off that the work should happen. |
| Approved | Someone with authority has accepted the work. | Moves to In progress once a technician actually starts. |
| In progress | A technician is actively working the job. | Moves to Complete when finished, or Waiting on materials if it stalls. |
| Waiting on materials | Paused because a part or material isn't on hand. | Returns to In progress once the material arrives. |
| Complete | All work is done and logged. | Moves to Closed once someone verifies it and signs off. |
| Closed | Locked. Nothing about the record can change again. | Nothing — this is the end state. |
Statuses and behavior from IBM's Maximo documentation. Maximo also blocks illegal jumps, like closing a work order that's still in progress.
You don't need Maximo's exact six states, but the shape is worth borrowing: a fixed list, one status active at a time, a timestamp on every change, and a closed state that nothing can undo. That combination, more than any single field, is what makes "when was this actually finished" an answerable question instead of a guess.
Terminology
Work order, service ticket, or something else?
The terms get used interchangeably, but each implies a slightly different set of fields and a different person responsible for closing it out. If a record in your app is called a work order but never gets a sign-off, it's probably a service ticket wearing a bigger name.
| Term | What triggers it | What it adds beyond the base fields | Who closes it |
|---|---|---|---|
| Work order | A reported problem, or an approved request | Assignment, parts and labor, a full status history | The technician, then a reviewer who signs off |
| Service ticket | Someone reports an issue | Usually just a description and contact info | Whoever resolves it, often becomes a work order once scheduled |
| PM task | A maintenance calendar or a meter reading, not a complaint | A checklist tied to the asset's PM schedule | Whoever performs the scheduled check |
| Punch list item | A walkthrough near the end of a project | A location or unit reference and a verified step | Whoever signs off the list, not necessarily whoever fixed it |
Picking an approach
Work order tracking, without the paper.
None of the fields above require a fancy tool, but most of the common ones make at least one of them impossible to get consistently.
| Approach | Real audit trail | Works offline in the field | Custom fields per trade | Who maintains it |
|---|---|---|---|---|
| Paper form / clipboard | No | yes, by default | yes, whatever you write | you, by hand |
| Spreadsheet | No | No | yes | you, and it drifts |
| Generic form builder | No | depends | limited | you, bolted together |
| Off-the-shelf CMMS / field service platform | Yes | Yes | locked to their schema | the vendor |
| Custom-built work order app | Yes | Yes | whatever your process needs | you |
Which row fits depends on how closely your work actually maps to a vendor's schema. Two neighboring categories are often a different job wearing a similar name: if what triggers the record is a maintenance calendar instead of a reported problem, that's really a preventive maintenance app; if it's a running list of finish-out items before a project closes, that's a punch list app, not a work order queue.
Free vs. paid
Is there a free work order app?
For one technician kicking the tires, sure. Most field service and CMMS platforms offer a free tier, but they cap it by number of users, work orders, or assets, and the fields most useful for an audit, custom fields, full status history, offline sync, are usually the first things reserved for a paid plan. Once more than a couple of people are opening work orders, budget for a real work order management app rather than stretching a free tier past what it was built for. Even a build-it-yourself platform like Newly starts at $25 a month, and dedicated field service platforms typically run well past that per seat.
When to build your own
Building a work order app that fits your process.
The honest reason to build your own work order app instead of buying one off the shelf usually isn't cost, it's fit. A team whose fields, statuses, or sign-off chain don't match what a vendor's schema assumes ends up either bending its process to the software or bending the software until it breaks. That gap, a process that no off-the-shelf tool quite fits, is what Newly is for: describe the work order you actually run, the fields, the statuses, who can close what, and it builds a real native app around your process instead of the vendor's.
The fields and statuses are the part worth nailing down on paper first, since they're cheap to change before anything is built. Wiring them to a real database, sign-off permissions, and offline sync is a separate decision, and it comes down to choosing a backend for your app, which is worth understanding before you start describing screens.
Sources
Where the specifics came from.
Two things on this page come from a primary source rather than general industry consensus:
FAQ
Work order apps, answered.
A work order app is used to create, assign, track, and close work orders, the formal record of a piece of work: what was requested, who did it, what it took, and when it was signed off. It replaces paper tickets and spreadsheets with a record that has a timestamped status history, so a manager can see what is open, overdue, or waiting on parts without calling a technician.
Start with the fields, not the form.
Work order apps live or die on the boring stuff: fields that don't go missing, and a status that can't be edited into lying. Get those right, then build the app around them in Newly.