Change Requests vs Work Orders: When to Use Each

Change Requests vs Work Orders: When to Use Each

Work orders and change requests look similar on the surface. Both assign work to someone. Both have a start and an end state. Both track who did what and when.

But they're built for different purposes, and using the wrong one has real consequences: missed approvals, no rollback plan, audit gaps, and teams confused about who had authority to do what.

This article explains the difference, covers the overlap zone where the choice isn't obvious, and classifies six real scenarios so you can apply the logic to your own operations.

What a Work Order Is

A work order is an instruction to perform a defined maintenance or service task. It's operational. A technician receives it, executes the work, and closes it out.

Work orders are used for:

• Repairing equipment that has failed or is degrading
• Executing a scheduled preventive maintenance task (oil change, filter replacement, calibration)
• Responding to a facility request (replace a light fitting, fix a leaking pipe)
• Running an inspection checklist on a vehicle or piece of equipment

The defining characteristic of a work order is that it's an autonomous execution task. The technician has the authority and the knowledge to do the work without additional approvals. The work order tells them what to do, on what asset, and by when. They do it, log the outcome, and close it.

Work orders don't require a back-out plan because the work is either reversible by default (you can replace a part again) or the scope is limited to one asset with no downstream dependencies that need formal notification.

Work orders don't require CAB approval because the decision to do the work was already made — either by a maintenance schedule, a manager, or a clear failure state that the technician is authorised to address.

The process is: request or trigger → assign → execute → close.

What a Change Request Is

A change request is a formal proposal to modify something: a system, a configuration, a process, or an environment. It's governance-driven. Before anything changes, the right people need to review and approve it.

Change requests are used for:

• Upgrading software versions on production systems
• Changing firewall rules or network configurations
• Modifying access controls or user permissions in production
• Deploying new infrastructure to a production environment
• Changing manufacturing process parameters on critical equipment
• Any modification that could have downstream effects beyond the immediate asset

The defining characteristic of a change request is that it requires formal sign-off before execution. The work shouldn't happen until the CAB (or whoever sits in the approval chain) has reviewed the plan, the testing evidence, and the rollback procedure.

Change requests require:

• Business justification for why the change is needed
• A testing plan with documented sign-off
• A back-out plan with a named rollback owner
• Formal approval from the right people
• A post-implementation review to confirm the change did what was intended

The process is: propose → document → review → approve → execute → verify → close.

The Core Difference

The cleanest way to understand the distinction:

Work orders are for tasks where authority to act is already established and the scope is bounded to a single asset or location.

Change requests are for modifications where the authority to act must be explicitly granted, and where the consequences could extend beyond the immediate scope.

A technician replacing a pump impeller doesn't need CAB approval. They need a work order, the right parts, and access to the equipment.

An engineer changing the pressure setpoints in a production control system does need formal approval, documented testing, a rollback procedure, and a record that shows who authorised it and when.

The test is simple: if the work went wrong and caused a problem, would anyone need to ask "who approved this?" If yes, it's a change request. If the answer is "it's a maintenance task, the technician had standing authority," it's a work order.

The Overlap Zone

The lines blur in a specific set of scenarios. The overlap zone is where most organisations make the wrong call.

The clearest example: deploying a software update to a production system.

On the surface, it looks like a task you assign to someone — just like a work order. But a software deployment on a production system:

• Can break dependent services if the version has compatibility issues
• Requires testing sign-off before it touches production
• Needs a rollback plan because reverting a bad deployment is not trivial
• Should be formally approved before it happens
• Creates an audit trail requirement in most compliance environments

That's a change request, not a work order. The fact that it gets executed by a single person doesn't change the governance requirements.

The confusion happens because teams use work orders for everything, find them easier to create and close, and end up with a maintenance log that shows "software update" work orders with no approval history, no testing documentation, and no back-out plan. When an auditor asks for the change record, there isn't one.

Six Scenarios, Classified

Scenario 1: The HVAC unit is throwing fault codes and needs a technician

Classification: Work Order.

This is reactive maintenance. The asset has failed or is degrading. A technician is authorised to diagnose and repair it. The scope is bounded to the HVAC unit. There are no downstream dependencies that require formal notification. No rollback plan is needed because repair work is the default recovery action.

Scenario 2: Monthly preventive maintenance on server cooling infrastructure

Classification: Work Order.

Scheduled maintenance tasks are work orders. The maintenance schedule is the prior approval. The technician executes a defined checklist, logs the outcome, and closes the work order. This is exactly what preventive maintenance schedules are for.

Scenario 3: Upgrading the building management system software from v3.4 to v4.0

Classification: Change Request.

A major version upgrade on a production building management system affects HVAC control, access control, and monitoring. It needs testing in a non-production environment first, a back-out plan if v4.0 has compatibility issues with the existing hardware configuration, and approval from whoever is accountable for building operations. This is a normal change requiring CAB review.

Scenario 4: Adding a new technician's account to the CMMS

Classification: Standard Change (or Work Order in some frameworks).

Low risk. Repeatable. Doesn't modify any production system. Adding a user account has no downstream dependencies that could fail. Most organisations treat this as a standard change (pre-approved, abbreviated process) or handle it via a service request workflow rather than a full change request. It should not require full CAB review.

Scenario 5: Changing firewall rules to open a new port for a vendor connection

Classification: Change Request.

Firewall rule changes affect network security posture. They need review from a security owner, documentation of what the rule does and why it's needed, and a back-out plan if the rule creates unexpected access. This is a normal change with security implications. CAB approval is required. "We'll just revert the rule if something breaks" is not a back-out plan — who reverts it, when, and how is the back-out plan.

Scenario 6: Emergency patch deployment after a zero-day vulnerability

Classification: Emergency Change Request.

Not a work order. Even emergency deployments need governance. An emergency change request uses an abbreviated process: shorter approval chain (a single security lead may suffice rather than full CAB), compressed timeline, and retrospective documentation completed within 24-48 hours. The authority to act is still granted formally, not assumed. The emergency process exists specifically so that urgent changes can move fast without bypassing accountability entirely.

The instinct to route emergency work as a work order to avoid paperwork is understandable. But a zero-day patch deployment with no change record, no named approver, and no verification that the patch was applied successfully is exactly the kind of gap that shows up in a security audit.

Summary Table

What Happens When You Use the Wrong One

Using a work order instead of a change request:

The most common mistake. A production software deployment gets logged as a work order. It closes when the deployment completes. If the deployment breaks something, the incident investigation finds a work order that says "deploy software update — complete." There's no testing record, no approval, no rollback plan, and no clear accountability. The audit trail is useless.

For compliance-sensitive operations — anything touching client environments, regulated industries, or security posture — this creates real exposure.

Using a change request instead of a work order:

Less common, but it happens when teams apply change management process to routine maintenance tasks. A technician can't replace a failed pump impeller without filing a CAB request and waiting for approval. Maintenance backlogs build. Preventive work gets delayed. Teams work around the process by logging informal fixes and doing the paperwork later, which defeats the purpose.

The right process applies the right governance. Routine maintenance moves fast because it doesn't need approval gates. Changes to production systems move carefully because they do.

Using Both in the Same Platform

The strongest operations teams use both work orders and change requests, and they use them in the same platform.

The reason is context. When a change request is filed to upgrade a production system, the linked asset record should show the asset's maintenance history: recent work orders, open faults, last service date, upcoming PM schedule. If the asset has a pattern of instability, that's relevant context for the CAB decision.

When a work order is created for emergency repair on a system that has an open change request, the technician should be able to see that a planned change is pending. If the repair work changes the system's configuration, that context matters.

Running work orders and change requests in separate systems creates gaps. The asset record in one system doesn't reflect what happened in the other. Audit trails are split across tools. Teams don't have full visibility into what's happening to an asset across both maintenance and change management workflows.

AssetOS work orders and AssetOS change requests share the same asset register. A technician closing a work order sees the open CRs on that asset. A CAB reviewer approving a change request sees the asset's full maintenance history. The distinction between work orders and change requests is enforced at the process level, but the data lives together.

That's the practical answer to "change requests vs work orders": not an either/or, but a both, managed consistently so nothing falls through the gap.