A work order management app is a state machine with somebody's name on every move.

Status is a state machine, not a text field

Start with the states, and keep the list short enough to hold in your head. Requested, approved, assigned, in progress, waiting on parts, done, verified, closed, plus rejected and cancelled for the jobs that never happen. Two of those splits carry most of the value. Requested against approved separates what somebody wants from what the business agreed to pay for. Done against verified separates the technician saying it is finished from somebody else agreeing. The same object turns up elsewhere as a service request or a snag, so a job ticket app is this build under another name.

The moves matter more than the states. For every state, write down which moves are legal and who is allowed to make them. A supervisor approves or rejects a request. A planner assigns it. Only the assigned technician starts it, pauses it for parts and marks it done. One dropdown holding all ten states is how you get a job that went from requested to closed with nobody ever assigned, and no way to tell whether the work happened at all.

Decide what closed means before you build it. Either closed is terminal, and a recurrence opens a new job that points back at the old one, or closed is a state you can move back out of. Both work. Choosing neither means the first argument about a repeat failure is settled by whoever edited the row last. A snag list on a building site is the same machine with fewer states, which is why a construction punch list app feels familiar once you have drawn this one.

Every move needs a name and a timestamp

Behind each of those moves sits a row in a second table: the job, the state it left, the state it entered, who moved it, when, and an optional note. Write rows, never edit them. The current state is then a derived thing, the last row in the history, and a question like how long this job waited on parts becomes arithmetic instead of recollection.

Regulated industries settled this argument decades ago, and the wording is worth copying even where the rule does not reach you. The FDA rule for electronic records, which applies where a site keeps records the agency requires, calls for secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. The same paragraph adds that record changes shall not obscure previously recorded information, and that the audit trail has to be kept at least as long as the record it describes. Those two sentences rule out the single status column that most trackers start with.

Attribution needs identity, and identity is the part people skip. We did not ship a work order app to check this, so we read what Newly's own documentation says a build starts with. A new app keeps its data on the phone: no accounts, no server, no sign-in. With no accounts there is nobody to name, so a status change can carry a timestamp and not a person. Ask for accounts, or for data shared between people, and the agent adds a backend: a sign-in service with email and password working immediately, an API service, a Postgres database for each environment, and file storage. States and a history table are ordinary rows in that database, so the machine above is something you describe rather than a feature to go hunting for. What documentation cannot tell us is how many prompts it takes to get the transition rules exactly right, and we have not measured that.

One more pair of fields, because it is expensive to add later. When the work happened and when it was recorded are not the same moment. A technician who finishes at four on Friday and closes the job on Monday morning has produced a record that reads as a weekend of downtime. Store both, and report on the first.

21 CFR 11.10, controls for closed systems, electronic records

The queue is the product

Nobody opens a maintenance work order app to browse. A technician opens it to find out what to do next, which means one screen holding their own jobs, ordered by when they are due, with no filter to set first. A supervisor needs a different list: unassigned, overdue, and anything that has been waiting on parts for more than a week. Same rows, two products, and the supervisor one usually gets built first by accident.

Priority only earns its place if something reads it. A word in a field changes nothing. Give each priority two targets, a respond by and a complete by, compute them from the moment the job was raised, and sort by whichever is closest. Then overdue is a query rather than a meeting. Skip it and the priority field becomes somewhere for people to express frustration.

The other reason jobs stall is that the thing needed to do them is elsewhere. A job that cannot start because the torque wrench is in somebody's van is a scheduling problem the app could see, if it knew where the tools were, which is the job of a tool tracking app. None of it helps if the app is unusable in the plant room where the work happens, so settle early what it does on a job with no signal.

Closing a job is a certification, not a tick

The federal process safety management rule has already written part of your schema. For covered processes, the employer must document each inspection and test performed on process equipment, and the documentation has to identify the date of the inspection or test, the name of the person who performed it, the serial number or other identifier of the equipment, a description of what was performed, and the results. Five fields, no adjectives. Copy that shape even where the rule does not apply to your site, because it is what anybody reviewing the job later will ask for.

The equipment identifier is the field people leave out and regret. A job attached to the words boiler room cannot be counted, compared or trended. A job attached to an asset record answers the question that actually decides budgets: whether this machine now costs more to keep than to replace. That means the asset list exists before the jobs do, even if it starts as forty rows typed in an afternoon.

Verification is the second signature, and it is what makes done mean something. Somebody who did not do the work looks at it, then either moves the job to verified or sends it back to in progress with a reason. Those send backs are the most useful rows in the whole history, because a repeat failure and a bad repair look identical in a system that only records successes.

29 CFR 1910.119(j), process safety management, mechanical integrity