How Maintenance Work Orders Flow Through a CMMS

An operator reports that pump P-104 makes a metallic rattle for about ten seconds after cold startup, then quiets down. What happens next determines whether the maintenance system produces controlled work, trustworthy history, or both. That sequence — from a sentence spoken at the plant to a record someone can still understand six months later — is the real subject of work-order workflow.

The familiar five-step lifecycle

REQUEST → APPROVE → ASSIGN → COMPLETE → CLOSE

You will recognize this picture. Nearly every CMMS product page shows some version of it, and it can be genuinely useful as shorthand for orientation. New technicians can use it to learn where their work sits. Managers can use it to explain the basics.

The problem is what the diagram hides. Between Request and Close sit most of the decisions that determine whether maintenance work is well controlled:

• Is P-104 correctly identified, and is this already reported?
• Does maintenance understand the observation, or only the wording of it?
• Does this require investigation before anyone can define the work?
• What work is actually justified, and what resources does it need?
• Is the work ready to schedule — and what does “ready” mean here?
• What if the technician finds something different after opening the equipment?
• What if part of the work cannot be completed, or a second condition is discovered?
• When is the physical work done, and when is the record complete?
• Did the original condition actually get resolved?

The maintenance process begins when a need becomes known — when someone notices something and the organization hears about it. It does not begin when somebody clicks “Create Work Order.”

What this guide adds to the other work-management guides

CMMSBuyersGuide covers work management in several guides, each with a distinct question.

What buyers should look for in software used to control maintenance work is the subject of our guide to maintenance work order software. How competing maintenance demand becomes credible commitments against finite resources is covered in maintenance scheduling software. What evidence must survive so maintenance can be understood later is covered in maintenance tracking software. How planning reduces uncertainty before execution is covered in maintenance planning software. The information exchange at the point of work is covered in our mobile CMMS guide, and what evidence triggers intervention is covered in our guide to preventive vs predictive maintenance.

This guide asks a different question: as a maintenance need moves through the organization, what changes — and what information must remain connected so the work still makes sense? It is about the end-to-end transformation of maintenance demand through the CMMS, including the handoffs, loops, decision gates and information losses between stages.

The thesis: a work order is the organization’s evolving representation of a maintenance need. Its lifecycle should progressively turn observation into controlled work, expected work into actual work, physical findings into accountable follow-up, and completed work into trustworthy organizational memory — while preserving the context that makes each step understandable.

Start before the work order

Maintenance demand can originate from many places: an operator observation, a technician discovery, an inspection, a preventive maintenance routine, condition monitoring, a failure or event, a regulatory requirement, an engineering finding, follow-up from existing work, or other legitimate sources. The list is illustrative rather than exhaustive.

A maintenance request or observation is not necessarily a work order. Mature enterprise maintenance architectures make this distinction explicit. SAP, for example, structures unplanned maintenance processing around the maintenance notification — which describes the condition of a technical object or reports a malfunction — and the maintenance order, which is used to plan the execution of maintenance tasks in detail, trace work progress and settle costs. A third area, the maintenance history, stores the most important maintenance data on a long-term basis for evaluation.

In SAP’s documented architecture, the notification describes and requests; the order controls execution; the history preserves the record for the long term[1].

A reported maintenance need is not necessarily a work order.

A work request describes what someone knows

The conceptual distinction is worth stating carefully.

A request or observation is what someone knows, notices, or asks maintenance to consider. A work order is a controlled representation of work the organization has decided to manage.

SAP’s standard notification types reflect this range: a problem notification reports a malfunction or problem that has occurred; a maintenance request asks for tasks to be performed; an activity report documents work that has already been performed[2]. The naming differs across products, and no buyer should expect every CMMS to use these terms.

A work request describes what someone knows. A work order should increasingly describe what the organization has decided to do.

Maintenance demand is not one-to-one

The relationship between demand and work varies. Consider the possibilities:

ONE REQUEST → NO NEW WORK ONE REQUEST → ONE WORK ORDER ONE REQUEST → MULTIPLE WORK ORDERS MULTIPLE REQUESTS → ONE WORK ORDER ONE WORK ORDER → MULTIPLE FOLLOW-ON WORK ORDERS ONE LARGE REQUIREMENT → MULTIPLE RELATED WORK PACKAGES

Three people may report that P-104 is noisy, that P-104 is vibrating, and that the pump sounds abnormal. These could be three different problems. They could also be three observations of one physical condition.

Enterprise systems explicitly support the many-to-one case. In SAP’s documented example, a planner creates an order for a malfunction report and then assigns three further malfunction reports requesting similar tasks to the same order, with all four notifications linked to the order’s object list[3].

Do not assume every CMMS supports every one of these structures. The buyer’s job is to determine which relationships matter for their operation and whether the software can represent them.

Maintenance demand and maintenance work are not necessarily one-to-one.

Screening is a decision process

Before accepted work exists, someone or something must screen demand. The outcomes can include accepting the request, rejecting it with no new work, or asking for clarification. The exact statuses differ across systems; the decision itself does not.

Screening goes beyond deciding whether a request is important. It decides whether the organization understands the maintenance need well enough to control what happens next.

No new work does not mean nothing happened

A request may end without new physical work for many legitimate reasons: it duplicates existing work, it gets merged or linked into other work, it is routed elsewhere, it requires no maintenance intervention, it rests on incomplete or incorrect information, or it is superseded by another response.

The principle: screening should decide what happens to the request without erasing the fact that the request happened.

Where a legitimate maintenance decision occurred, making the record disappear can also make the reasoning disappear.

This matters more than it first appears. The set of requests that did not become work is itself maintenance information — evidence of what was considered and why the organization chose otherwise. A system that can only show you the work it accepted has already discarded part of its own decision history.

CMMSBuyersGuide model: the Work-Order Information Transformation

This is a CMMSBuyersGuide explanatory model, not an industry standard. Its purpose is to show what is actually changing as maintenance demand moves through the system.

OBSERVATION Messy physical reality. What did someone notice? ↓ MAINTENANCE NEED Screened reality. What do we believe deserves maintenance attention? ↓ SCOPE Decided response. What do we believe needs to happen? ↓ PLAN Expected work. What will it take? ↓ READINESS Prepared work. Do we know enough, and have enough in place, to responsibly commit it? ↓ COMMITMENT Authorized / scheduled / assigned work. What resources and time are we committing? ↓ EXECUTION Physical work. What actually happened? ↓ FINDING Physical reality talks back. What did we discover? ↓ DISPOSITION What remains? ↓ HISTORY What should future people understand?

History then feeds future planning and maintenance decisions. And the flow allows loops backward whenever new information invalidates previous assumptions — a finding during execution can send work back to planning, and a clarification request can send a request back to the reporter.

Notice what each stage changes: the stage transforms the information. An observation becomes a need only after someone decides it deserves attention. A need becomes scope only after someone decides what should happen. The work order is the record that carries these transformations.

The work order has multiple lives

The same record serves different purposes at different times.

• Decision object: should this become controlled maintenance work?
• Planning object: what scope, resources, materials, access and coordination are expected?
• Execution object: what is happening physically, right now?
• Historical object: what should future users believe happened?

The same work order has to coordinate future work, represent current work and eventually explain past work.

Most workflow problems in real installations trace back to treating the work order as if it had only one of these lives. A system optimized purely for execution makes thin history. A system optimized purely for history makes technicians drown in closeout fields. The record’s job changes, and the workflow should acknowledge the change.

Planning wants prediction. History wants truth.

Before execution, the record holds predictions: planned scope, planned labor, planned material, planned duration, expected condition. After execution, it holds evidence: actual work, actual labor, actual material, actual duration, actual finding.

No organization records every item, and the relevant fields differ by industry and by job. The principle survives the variation:

Planning data is a prediction about work. Completion data is evidence about work.

Both deserve to survive. When actual work differs from planned work, overwriting the plan destroys the very comparison that would let the organization learn. The plan should remain visible next to the actual — a principle our guide to maintenance planning develops in depth.

Related guide: Maintenance Planning Software

Plan variance is maintenance evidence

Suppose the P-104 plan calls for two technicians, three hours, inspect and replace seal. The actual result: two technicians, seven hours, plus additional coupling work.

The variance has many possible explanations: incomplete original scope, an unavoidable discovery, changed physical condition, access difficulty, a preparation issue, or other legitimate causes. Nothing in the numbers alone tells you which.

The difference between planned work and actual work is itself maintenance evidence.

Plan variance should be preserved before the organization tries to explain it. Explaining comes next; erasing comes never. A variance that is quietly absorbed into an edited plan cannot later improve estimating, cannot reveal a recurring preparation problem, and cannot show that a job plan is systematically optimistic.

The original observation must survive planning

Return to the operator’s words: “P-104 makes a metallic rattle for about ten seconds after cold startup, then quiets down.”

The planner may legitimately convert this into “Inspect drive assembly.” That conversion is useful — planning requires abstraction. But consider what the technician sees if the original wording is gone: a task, without the operating context that gave it meaning. The phrase “after cold startup, then quiets down” may be the single most diagnostic fact in the entire case, and it vanished somewhere between the request and the job plan.

A work-order process can make information cleaner while making it less true to the original observation.

The remedy is structural: structured data should organize maintenance information without erasing the part that did not fit the structure. Original wording, photos, operating context and attachments belong somewhere the technician can still reach them after conversion.

Handoff loss

Handoff loss takes recognizable forms at each stage boundary:

• Requester to screening: the operating context behind the report disappears.
• Screening to planning: the original symptom gets reduced to a generic problem code.
• Planning to scheduling: an access constraint disappears from the record.
• Planning to technician: the job plan arrives without the original evidence.
• Technician to closeout: a specific physical finding becomes the word “fixed.”
• Closed record to future user: the work relationship or context is no longer visible.

A maintenance system can suffer information loss even when the original information was good.

That last point deserves emphasis. Handoff loss is frequently blamed on careless reporters or rushed technicians. Often the system design is the cause: a form with no room for context, a conversion that discards free text, a mobile view that hides the request. Fixing handoff loss is a workflow-design problem before it is a people problem.

Work management is partly an information-compression problem

Humans summarize reality at every stage. The operator summarizes a sound. The screener summarizes a report. The planner summarizes a need. The technician summarizes a finding. The summarizing is necessary — no system can carry everything — and each summary can discard useful context.

A good work-order process reduces uncertainty without throwing away the evidence that future decisions may still need.

The practical question for buyers: at each stage conversion in the workflow, what does the system do with the information that did not make it into the structured fields? Where does it go, who can still see it, and for how long?

Planned does not mean ready

A work order can have complete scope and still lack something needed for execution. The possible considerations include materials, labor and skill, tools, instructions and documents, access, coordination with production, permits and authorizations where applicable, and external support. Every organization weights these differently, and no universal readiness checklist exists.

“Ready” is not a date. It is a claim about the quality of preparation.

This distinction has direct scheduling consequences:

Scheduling unready work does not make it ready. It assigns a date to uncertainty.

The readiness boundary

This is a CMMSBuyersGuide explanatory visual. It marks the line between preparing work and committing it.

IDENTIFIED / ACCEPTED WORK ↓ PLANNING Reduce enough uncertainty. ↓ READINESS BOUNDARY ↓ SCHEDULING / COMMITMENT Commit prepared work against finite resources, time and access. ↓ EXECUTION

The boundary connects directly to two existing guides. How planning reduces uncertainty before execution is the subject of our maintenance planning software guide, and how prepared work becomes credible commitments against finite resources is the subject of our maintenance scheduling software guide. This article focuses on the boundary between them and what crossing it should mean.

Release: the boundary between preparing and authorizing

Mature maintenance architectures treat authorization as a distinct event. In SAP’s documented process, site employees cannot start the defined activities until the order is released; only after release can certain execution activities occur, such as withdrawing material and creating time confirmations[4]. Release is a separate step from creation and planning, and it changes what execution functions become available.

SAP’s terminology is an SAP example, not an industry standard. The broader principle stands on its own:

There can be a meaningful boundary between preparing work and authorizing execution.

And the boundary should mean something:

A workflow transition should represent a real change in what the organization knows, permits or commits — a change with consequences, rather than a different label.

CMMSBuyersGuide model: Progressive Commitments

This is the second CMMSBuyersGuide explanatory model in this guide. As work progresses, the organization makes increasingly consequential claims.

OBSERVED “We acknowledge an observation.” ↓ ACCEPTED “We recognize this as maintenance demand.” ↓ DEFINED “We believe we understand the work sufficiently.” ↓ READY “We believe preparation is sufficient to commit execution.” ↓ COMMITTED “We have allocated time, resources and responsibility.” ↓ EXECUTED “We physically performed work.” ↓ VERIFIED / DISPOSITIONED “We understand what was done and what remains.” ↓ FIT FOR HISTORY “We believe this record is sufficiently trustworthy to become maintenance history.”

This progression is not always linear. Physical discovery can send the process backward — a finding during execution can return work to definition or planning. The model describes the accumulation of organizational commitment, and discovery can force some of that commitment to be revisited.

A status should represent a business claim

A vendor may show a workflow with the states Open, Assigned, In Progress, Complete and Closed. The buyer question is simple to ask and demanding to answer: what does moving from one state to the next actually mean?

• Did scope become defined?
• Did work become ready?
• Did execution become authorized?
• Did physical work begin?
• Did physical work finish?
• Did required information become complete?
• Did remaining work receive a disposition?

A status should describe a meaningful change in the state of the work — a change in what the organization knows, permits or commits — rather than a change in the label attached to it.

Ask what operational claim each status represents and what decision becomes possible because of it. If nobody can answer, the workflow may be cosmetic.

Too few states versus too many states

The right number of statuses depends on the operation, and this guide argues for no specific count. The failure modes sit at both extremes.

Too few states can hide important differences. A single “In Progress” state might mean planning is underway, the job waits for a part, the job is scheduled, a technician is actively working, or the job waits for production access. Those five situations call for different responses, and a workflow that cannot express the difference forces everything else — notes, emails, hallway conversations — to carry it.

Too many states create their own problems: inconsistent use, data-entry burden, false precision, and confusion about which state applies. People stop trusting labels that nobody applies the same way twice.

More workflow states do not automatically create better process visibility.

The better buyer question: can the workflow represent the few operational distinctions that actually change what happens next?

Work state and blocking reason are different questions

Consider two examples. Work state: planned. Blocking reason: material unavailable. Or work state: execution interrupted. Blocking reason: additional scope requires review.

The two fields answer different questions. Where the work is and why it cannot move are different questions, and collapsing them into a single “On Hold” state discards the second answer entirely.

“On hold” describes inactivity. It does not explain the constraint.

A backlog full of on-hold work orders tells you that nothing is moving. A backlog that distinguishes waiting-on-material from waiting-on-access from waiting-on-review tells you what to fix first. This is one place where a small amount of additional structure changes daily management, not just reporting.

Backlog is not one pile

A count such as “700 open work orders” may combine very different things. These queues are a CMMSBuyersGuide explanatory model for reading a backlog — they are not universal CMMS categories, and products implement them differently or not at all.

• Demand: awaiting screening or clarification.
• Definition and planning: accepted but not sufficiently prepared.
• Constrained: cannot currently move because something is missing.
• Ready: prepared enough to schedule.
• Committed: scheduled, assigned or authorized.
• Execution: active or interrupted physical work.
• Closeout: physical work sufficiently complete, record or disposition still unfinished.

Open work count is not the same thing as executable maintenance demand.

Backlog is work in different states of knowledge, readiness and commitment. The composition of the backlog usually says more about the maintenance organization than the total does: a backlog that is mostly definition work has a planning constraint; a backlog that is mostly closeout has a closeout constraint; a backlog that is mostly constrained work has a materials or access problem.

Age and elapsed time need context

A 30-day-old unscreened request means something different from a planned turnaround job intentionally waiting for a future outage, or a physically completed work order waiting 30 days for closeout. The number alone carries no verdict.

Work-order age has meaning only in relation to the state the work is in and why it is there.

Elapsed time and labor time diverge the same way. A work order may exist for 30 days and involve four hours of physical maintenance. The other time went into screening, planning, material procurement, access coordination, scheduling, waiting, and closeout. Where did it go?

Work-order elapsed time is not the same thing as maintenance labor time.

The spaces between maintenance activities can matter as much as the activities themselves. But absence of evidence cuts both ways: do not infer delay from a large gap without knowing what the gap contained.

State versus event history

Two different questions, two different kinds of data.

State answers: where is the work now? Event answers: what happened that moved it there?

EVENT: technician found additional damage ↓ STATE: execution paused / constrained ↓ EVENT: required material became available ↓ STATE: execution resumed

This distinction does not require any particular database architecture, and buyers should not evaluate products on buzzwords like event sourcing. The operational question is simpler: can the record show the sequence of transitions, with reasons where people entered them?

A status is a snapshot. Work history is a sequence.

The current state tells you where the work is. Transition history tells you where the process spent its time.

Workflow analytics depend on workflow meaning

If everything in flight is labeled In Progress, analytics cannot reliably distinguish a planning delay from a material constraint, a schedule wait, active execution, or a closeout delay. The dashboard will still render. The bars will still fill. The analysis underneath will be guesswork.

You cannot analyze a maintenance process more precisely than the process states your data actually distinguishes.

The counterweight matters too: more statuses do not create better analytics if people cannot use them consistently. Analytical power comes from states that are few enough to be used honestly and distinct enough to carry meaning. That balance is an organizational design decision, and it is worth making deliberately during implementation.

Execution is where physical reality gets a vote

The planner expects to replace a seal. The technician opens the equipment and finds a different or additional condition. Now scope may change, material may change, duration may change, follow-up may be needed, work may pause, and planning may need revision.

Physical reality can invalidate the plan.

This is not evidence of planning failure. Some conditions cannot be known until equipment is opened, and a plan that anticipated everything would be too expensive to produce for most work. The mark of a good workflow is different:

A work-order workflow needs to handle learning that sends the job backward without pretending the process failed.

Buyers should test this directly in demos. What happens in the software when the technician discovers something the plan did not anticipate? Can the discovery be recorded, can scope change be reviewed, and does the record keep the story straight?

The happy path is not the real path

HAPPY PATH REQUEST → PLAN → SCHEDULE → EXECUTE → CLOSE

REAL PATH OBSERVE ↓ SCREEN ↺ clarify ↓ DEFINE ↓ PLAN ↺ resolve constraints ↓ READY ↓ COMMIT ↓ EXECUTE ↓ DISCOVER ↺ replan if needed ↓ COMPLETE PHYSICAL WORK ↓ DISPOSITION REMAINING CONDITION ↺ follow-on work if needed ↓ CLOSE ↓ HISTORY ↓ future work and planning

Maintenance workflow repeatedly converts incomplete information into decisions — and physical work can create new uncertainty after earlier uncertainty was already reduced.

Plan versus actual

The work order should carry both sides of the job without letting either overwrite the other.

WHAT WE THOUGHT Planned scope. Expected resources. Expected duration. ↓ PHYSICAL EXECUTION ↓ WHAT WE FOUND / DID Actual finding. Actual intervention. Actual resources and time, where captured.

A useful work order should preserve both what we intended to do and what actually happened.

Where actuals are captured matters.

In SAP’s documented model, completion confirmations capture who performed work, when it started and finished, what materials were used and how far processing has progressed[5].

A buyer does not need SAP’s fields. The buyer needs to know whether the system they are evaluating can keep planned and actual information distinguishable for the work that matters to them.

Partial execution

One work order may contain several operations or tasks. Some may finish while others cannot. What then?

Mature architectures answer at the operation level: SAP’s completion confirmations distinguish partially confirmed operations from a final confirmation, and the order receives its own status as operations complete[5]. No buyer should require their CMMS to mimic SAP. The teachable principle is independent of the product:

Order-level status can hide operation-level reality.

A second principle follows: the work order may be the container for controlled maintenance without being the smallest unit of execution. For long jobs, multi-trade work, or jobs with independently completable tasks, that distinction matters.

Buyer question: can the system represent partial execution without pretending the entire job is finished? Avoid evaluating vague percentage-complete logic on its own — percentages mean something only when the underlying workflow supports them.

Interrupted work has two stories

If work stops after execution has begun, the record has to hold two accounts at once.

• Execution history: what happened during this attempt?
• Remaining work: what must happen next?

The current status should not erase what already happened during an interrupted job.

An interruption is not a blank. Materials may be partly consumed, the equipment may be partly disassembled, access may have been granted and expire, and the discovery that caused the interruption is fresh evidence. A workflow that jumps from In Progress back to a generic open state discards all of it.

Work creates work

This is a core concept of work-order flow. Inspection may discover a repair need. Repair may discover an additional condition. Execution may reveal work requiring different resources or skills. A completed intervention may itself require follow-up.

MAINTENANCE NEED ↓ WORK ↓ PHYSICAL DISCOVERY ↓ NEW MAINTENANCE NEED ↓ FOLLOW-ON WORK

A work order can be both the result of maintenance demand and the source of new maintenance demand.

Serious enterprise architectures explicitly preserve these relationships. SAP’s documented follow-on order function creates a relationship to the reference order or operation and displays that relationship in the document flow, in a hierarchical structure[8].

A documented finding is not a controlled follow-up

The technician writes: “Small oil leak observed at gearbox input. Not addressed today.” The original work order closes. What happens to that condition?

If nothing happens, the leak was documented but not controlled. It lives in a notes field that nobody owns, and the organization will rediscover it — or its consequences — later.

Recording discovered work is not the same thing as creating accountability for discovered work.

Follow-up escape is one of the quietest sources of lost maintenance work. The finding is written down — the system shows no gap — and the condition still receives no decision. In demos, this is one of the highest-value behaviors to test: enter a discovered condition during execution, close the original scope, and ask the vendor exactly where that finding goes.

Work lineage

If work order 100 creates work order 127, the relationship is part of the maintenance story. Preserve it conceptually, in whatever form the product supports.

Follow-up work without lineage turns one maintenance story into unrelated records.

Two broad relationship patterns cover most needs:

• Sequential continuity: one piece of work leads to another — inspection leads to repair, repair leads to follow-up.
• Hierarchical continuity: a larger maintenance requirement contains or coordinates several subordinate work packages.

SAP’s documented sub-order function supports the hierarchical pattern: subordinate orders carry a superior order in their header and appear in multi-level order lists[9]. No specific parent-child software architecture is required — the principle is what matters:

Relationships between work records can preserve context that classification alone cannot.

A shared asset number and a shared week tell you the records coexisted. An explicit relationship tells you the organization connected them on purpose.

Maintenance history is more than a chronological list

A typical equipment history reads like this: January 2, work order 100; January 18, work order 112; February 4, work order 141. That chronology is useful. It is also incomplete when the records were related.

REQUEST ↓ INSPECTION WORK ORDER ↓ DISCOVERED DEFECT ↓ REPAIR WORK ORDER ↓ FOLLOW-UP

Chronology tells you sequence. Work relationships tell you which records the organization explicitly connected.

One caution applies to both: do not infer causality merely because records occurred close together in time. Proximity is a hint; an explicit relationship is a claim.

CMMSBuyersGuide model: the Work-Order Continuity Model

This is the third primary CMMSBuyersGuide model in this guide. Where the Information Transformation model shows what changes stage by stage, the Continuity Model shows what must stay connected across the whole life of the work.

ORIGINAL EVIDENCE What was observed? ↓ DECISION Why did this become controlled work? ↓ INTENDED WORK What did we plan? ↓ ACTUAL WORK What happened? ↓ PHYSICAL FINDING What did we discover? ↓ REMAINING CONDITION What remains? ↓ FOLLOW-ON / DISPOSITION What happens next? ↓ HISTORY What should future people understand?

The visual is designed to reinforce continuity rather than status progression. A closed work order that has lost the link between its original evidence and its actual work may satisfy the workflow and still fail the history.

A work order can close while the maintenance story remains open

Consider a P-104 vibration problem that spans three work orders: an inspection that completes legitimately while the underlying condition remains; bearing work that addresses part of it; and an alignment follow-up. Each work order has a clean lifecycle. The problem lifecycle is longer than any of them.

A work order can close while the maintenance story remains open.

Work completion and problem resolution operate at different levels.

For work initiated by a reported condition, the question is: did completing this work resolve the condition that caused it to exist — or did it create or require another controlled next step? The question does not apply everywhere. A preventive or inspection work order often has no problem to resolve, and treating every PM as if it must fix something leads to confused metrics.

Our guide to preventive maintenance software covers recurring work on its own terms.

Cancelled and do-not-execute work

Not every legitimate work record ends with physical maintenance. Mature systems can support a do-not-execute or cancelled outcome. SAP’s documentation even allows business completion when planned work steps were not all performed, with the order status left as “not performed”

— an explicitly documented path for closing work whose planned steps did not all happen[6]. The reasons vary — a duplicate, a superseding decision, a condition that changed, a request that screening resolved — and no universal rule applies.

“Do not execute” can be a legitimate maintenance decision — a considered outcome, rather than an abandoned work order.

The distinction worth protecting: cancelled work is not the same thing as work that never existed. Where a legitimate decision occurred, the reason work was not executed belongs in the record.

Buyer question: can we distinguish work intentionally not executed from completed work, failed attempts, duplicates, or records that simply disappeared?

Completion is not one fact

Mature systems distinguish completion stages. SAP, for example, separates technical completion — the order is marked complete for Plant Maintenance, while confirmations may still be entered — from business completion, which requires technical completion, settlement and resolution of outstanding commitments, after which the order is locked for postings

SAP separates technical completion of an order from business completion, which additionally requires settlement and resolution of outstanding commitments[7].

The exact terms belong to SAP. The underlying questions are general, and different systems and organizations handle them differently:

1. Is the physical work done?
2. Is the technical record complete enough?
3. Has remaining work been dispositioned?
4. Is the record ready to become history?
5. Are other administrative or financial consequences still open?

“Done” can describe several different states that should not automatically collapse into one checkbox.

Physical completion versus record closure

This is one of the most consequential gaps in real work-order data, and it deserves its own section.

The machine is back in service. Production is satisfied. But the record may still lack the actual work description, the finding, the follow-up decision, relevant labor or material information, required coding, or verification. The physical intervention and the information record have diverged.

The physical intervention can be finished before the maintenance record is finished.

No universal closeout checklist applies across industries. The buyer question is whether the workflow can tell the difference — whether the system distinguishes a record whose physical work is complete from a record that is actually ready to become history. Where that distinction is absent, closeout debt accumulates invisibly until someone needs the history and finds it unfinished.

Closeout is a conversion event

Before closeout, the work record primarily coordinates action. After closeout, it increasingly serves as evidence of past action. Closeout is where the record changes jobs.

Closeout converts a work-management record into a maintenance-history record.

Today’s closeout is tomorrow’s planning data.

Enterprise architectures are built around this conversion. SAP’s documented processing model reserves a distinct long-term area — the maintenance history — for the most important maintenance data, available at any time for evaluation and future planning[1].

Workflow completeness is not information completeness

A CMMS can require every field. The technician, under time pressure, can still enter “Fixed.” or choose the nearest code without useful context. The system reports the record 100 percent complete. The historical value is close to zero.

A record can satisfy every required field and still fail to explain what happened.

This is not a technician failure. Workload, interface design and workflow design shape what people enter. A closeout form that takes twelve minutes on a mobile device in a plant corridor will receive twelve seconds of thought wherever it can. If history quality matters to you, watch how the workflow asks for it.

Our guide to mobile CMMS covers the point-of-work information exchange in detail.

CMMSBuyersGuide model: physical flow versus information flow

The fourth primary model in this guide. Physical maintenance runs as its own process; the CMMS manages an information representation of it.

PHYSICAL FLOW ASSET CONDITION ↓ PHYSICAL INTERVENTION ↓ RESULTING CONDITION running beside INFORMATION FLOW OBSERVATION ↓ REQUEST ↓ SCOPE / PLAN ↓ WORK RECORD ↓ ACTUAL / FINDING ↓ HISTORY

A work-order system is trying to keep an information process synchronized with a physical maintenance process. The synchronization is never perfect, and it fails in recognizable directions:

• Information ahead of reality: the work order is marked complete before the physical work is actually complete.
• Reality ahead of information: the repair is finished, and the CMMS still shows the job active.
• Information misrepresenting reality: the plan says the seal was replaced; the technician actually repaired a different component.
• Reality creating new information: execution discovers an additional condition no plan mentioned.

Perfect real-time synchronization is not the requirement, and demanding it will exhaust any organization. The requirement is synchronization trustworthy enough for the decisions that depend on it.

Status latency

Physical reality changes; the CMMS gets updated later. Sometimes the lag is harmless. Sometimes a planner schedules against a record that no longer describes the equipment, or a report counts work as complete that physically finished differently.

A status is useful only to the extent that users understand how closely it reflects physical reality.

This is one of the places where the point-of-work exchange matters: our mobile CMMS guide covers how technician updates travel between the field and the system.

History fidelity

History fidelity is not a score, and it should not be turned into one. It is a set of questions about what survives:

• The original request and its context
• Attachments and photos
• Planned versus actual information
• Findings
• Work relationships and follow-on lineage
• Status and event history
• Relevant labor, material and cost information
• Whatever else matters to your use case

Retention requirements vary widely, and nothing here argues that all information must be retained forever. The buyer question is which parts of the context your organization will need, and whether they survive.

The long-term record

Another handoff hides at the end of the lifecycle: the live record, the closed record, and the long-term history are not automatically the same object.

SAP’s own documentation treats maintenance history as a distinct long-term storage area, with notification data explicitly transferred to it for evaluations and future planning[2]. The historical representation of a record can differ from the full live-order record. Do not generalize SAP’s behavior to every CMMS — but do ask every vendor the underlying question.

“Stored in the CMMS” does not automatically mean every part of the live record remains available forever at the same level of detail.

Strong buyer question: ask how long maintenance history is retained, and what version of the record survives. Both halves of that question matter.

Our guide to maintenance tracking software examines what evidence must survive so maintenance can be understood later; this section covers where it goes.

Vendor demo tests

The thirteen tests below are designed to expose the distinctions this guide has built. Run them against real product instances with your own scenarios wherever possible. None of them requires the vendor to have a specific feature name; each asks what the workflow actually does.

Demo 1: The original observation test

Enter: “P-104 makes a metallic rattle for about ten seconds after cold startup, then quiets down.” Move it through request, screening, approved work, planning, and the assignment or mobile technician view. Then ask: can the technician still see what the operator actually observed? This tests handoff loss.

Demo 2: Three requests, one problem

Enter three related reports: P-104 noise, P-104 vibration, abnormal pump sound. Ask: can the system preserve all observations without forcing them into three unrelated work orders? Then ask how duplicate or related demand is handled in practice.

Demo 3: A request that does not become work

Submit a valid maintenance request and disposition it without creating new physical work. Six months later, can we tell what was reported and what decision was made? This tests negative-decision history.

Demo 4: The ready-to-schedule test

Take an accepted but incompletely prepared work order. Ask what prevents it from being treated as ready. Then satisfy the organization’s relevant readiness requirements and ask what meaningfully changed. This tests whether readiness is operational or cosmetic.

Demo 5: Plan meets reality

Plan an inspect-and-replace-seal job. Have the technician find a different or additional condition. Ask: can planned scope remain visible? Can the actual finding be preserved? Can the job return to planning or review if needed? Can actual work differ from planned work without rewriting history?

Demo 6: The partial execution test

Create a work order with three operations or tasks. Complete two. The third cannot proceed. Ask: can completed work be recorded without pretending the entire order is finished? Then: what remains accountable, and why can’t it move?

Demo 7: The buried finding test

During execution, enter: “Small oil leak observed at gearbox input. Not addressed today.” Close the original scope. Ask where that finding goes. Can it remain visible, receive a disposition, create or link follow-up, and stay connected to the original work — or does it disappear inside notes? This tests follow-up escape.

Demo 8: Work creates work

During a work order, discover a legitimate follow-up need and create the follow-on order. Six months later, can someone see why the follow-up exists and which earlier work created it? This tests work lineage.

Demo 9: The do-not-execute test

Create approved work. Later determine that physical execution is not required. How do we disposition it without pretending it was completed — and without deleting the decision history?

Demo 10: Physical complete versus record closed

Have the technician finish the physical work and deliberately leave closeout information incomplete. Can the system distinguish physical completion from a record that is actually ready for history?

Demo 11: The status journey test

Take a recently closed work order and ask the vendor to show meaningful transition history. Can you understand intake, clarification, planning, constraint or wait, readiness, commitment, execution and closeout — wherever the product captures them? Then ask: can we tell where elapsed time accumulated? The exact states will differ; the visibility is the point.

Demo 12: The six-month test

Open a representative closed work order. Pretend nobody involved is available, and ask someone new to explain what happened. Can they determine why the work existed, what was originally observed, what was planned, what actually happened, what was found, what remained, and whether follow-up resulted?

If a closed work order cannot explain itself six months later, the workflow may have completed — and the maintenance history did not.

Demo 13: The archive test

Ask what happens to a work record after three years, under the vendor’s product and typical customer configurations. What remains accessible? What gets summarized? What relationships, attachments, search and reporting or API access survive? What retention rules apply? Do not assume unlimited history.

Ask how long history is retained, and what version of the record survives.

The distinction wall

Every distinction below was developed earlier in this guide. Together they form a compact checklist for evaluating any work-order workflow.

• REQUEST ≠ WORK ORDER
• OBSERVATION ≠ SCOPE
• ACCEPTED ≠ PLANNED
• PLANNED ≠ READY
• READY ≠ SCHEDULED
• SCHEDULED ≠ EXECUTED
• ASSIGNED ≠ UNDERSTOOD
• PLAN ≠ ACTUAL
• WORK STATE ≠ BLOCKING REASON
• STATUS ≠ PHYSICAL STATE
• CURRENT STATUS ≠ PROCESS HISTORY
• ORDER STATUS ≠ OPERATION STATUS
• PHYSICALLY DONE ≠ INFORMATION COMPLETE
• WORKFLOW COMPLETE ≠ INFORMATION COMPLETE
• WORK ORDER CLOSED ≠ CONDITION RESOLVED
• CANCELLED ≠ NEVER EXISTED
• DOCUMENTED FINDING ≠ CONTROLLED FOLLOW-UP
• FOLLOW-UP WORK ≠ UNRELATED WORK
• OPEN WORK ≠ EXECUTABLE BACKLOG
• WORK-ORDER AGE ≠ LABOR TIME
• CHRONOLOGY ≠ WORK LINEAGE
• STRUCTURED DATA ≠ COMPLETE CONTEXT
• MORE STATUSES ≠ BETTER VISIBILITY

Buyer questions

These questions are ordered along the lifecycle developed in this guide. Use them to structure product evaluations; the sections above explain why each distinction matters.

Intake and screening

• Can someone without a CMMS licence submit a maintenance request, and can we control what they see and can change?
• How does the product distinguish a request from a work order in its data model, not just its screens?
• When a request is declined or merged, what record remains, and can we later see what was reported and what was decided?
• Can multiple related observations be preserved as related demand rather than as unrelated duplicate records?
• What information is required before a request can be screened, and can we configure that without development work?

Planning and readiness

• How does the product distinguish work that is accepted from work that is planned from work that is ready to be scheduled?
• What must be true for a work order to count as ready in your own operation, and can the product represent those requirements?
• Can we see how long work has waited in each stage, including the reasons it could not proceed?
• When a plan changes, can we preserve what was originally planned rather than overwriting it?
• Can planning information travel with the work to the technician, and can field observations travel back without leaving the work-order context?

Status and workflow

• How many statuses does the product offer, and are they enough to represent our real states without inventing workarounds?
• Can a blocking reason be captured separately from the work state, so we can tell why work is not moving and whether it is still valid?
• Which statuses appear in backlog reports, and who decides that?
• Does the product capture event history for a work order, or only its current status?
• Can we distinguish elapsed time from labor time in our reporting?

Execution and partial work

• Can a work order contain several operations or tasks whose completion is tracked separately?
• If part of the work is done and part cannot proceed, can the record show both facts without pretending the whole order is finished?
• When work is interrupted, does the record preserve what happened during the attempt and what must happen next?
• Can the technician record actual work that differs from the plan without rewriting the plan?
• Can the job return to planning or review when execution reveals something the plan did not anticipate?

Discovery and follow-up

• When a technician documents a discovered condition that will not be addressed today, where does that finding go?
• Can a discovered condition be given a controlled disposition, or does it remain a note in a closed record?
• When execution creates follow-up work, is the relationship between the original order and the follow-on order preserved?
• Can we see a maintenance story spanning several orders, rather than a list of separate records?
• How are requests that do not become work kept distinct from records that disappeared without a decision?

Closure and history

• Does the product distinguish physical completion from a record that is ready to become history?
• What is required before a work order can close, and can we configure those requirements per work type?
• Can work be closed as intentionally not executed, with the decision preserved rather than deleted?
• What happens to a record after closure — is anything summarized, archived or dropped?
• How long is maintenance history retained, and what version of the record survives: the full live record or a reduced one?

Analytics

• Can reporting distinguish the stages of the lifecycle developed in this guide, or does it collapse everything into open and closed?
• When this month's completed work count is higher, can we tell whether that reflects demand, planning, readiness, capacity or execution?
• Can backlog reporting show age by stage and by blocking reason, not just a single open duration?
• Can closed work orders be found by their original request context, their findings and their follow-up relationships, beyond asset and date alone?

Fit

• Take a representative closed work order from our own history: can this product reproduce that story end to end?
• Where in this product would our organization's real handoffs lose information, and what would the system show when that happens?

Back to P-104

At the start of this guide, an operator reported that pump P-104 makes a metallic rattle for about ten seconds after cold startup. From that single observation, this guide followed everything a CMMS work-order workflow must do: screen the request without losing the observation; decide whether the organization understands the need well enough to control what happens next; plan the work; determine when it is genuinely ready; release it into scheduled, controlled execution; preserve what the technician actually found and did; disposition the condition the work discovered; and convert the finished record into history the organization can trust.

None of that is a five-step diagram. The diagram is a summary for people who already know the workflow. The workflow itself is a chain of progressive commitments, each with its own information state, its own failure modes, and its own evidence.

The Six-Month Test from the demos is the single most compact evaluation we can offer: take a representative closed work order, pretend nobody involved is available, and ask someone new to explain what happened and why. If the record can answer — what was observed, why the work existed, what was planned, what actually happened, what was found, what remains, and where it went next — the workflow is working. If it cannot, the workflow may have completed and the maintenance history did not.

That is the standard against which any CMMS work-order workflow deserves to be evaluated.