Work order resolutions

What it does

Resolutions are a reusable list of outcomes — "reset device control unit", "replaced condenser fan", "no fault found" — that you associate with incident types and record against a work order incident when the job is done. They give you structured outcome data instead of a free-text notes field nobody can report on.

Key facts

Resolution records are created under Settings > Work Order > Resolutions. They are lightweight: a name and a description, and that's genuinely most of it.
Resolutions are mapped to incident types. The primary resolution maps to the primary work order incident type by default.
An administrator can associate multiple resolutions with a single incident type when configuring that incident type.
When an incident type is added to a work order, the resulting work order incident surfaces the resolutions associated with that incident type as suggestions.
Resolutions sit on the work order incident, not the work order header. On a multi-incident job each incident carries its own outcome, which is the right model and often not what clients expect.
Incident types list Resolutions among their related records, alongside products, services, service tasks and characteristics — configure them in the same place and the same sitting.
The documentation page carries no preview banner and no release wave qualifier, so treat this as generally available functionality rather than something to hedge on.
Resolutions are separate from work order system status. Recording a resolution does not close, complete or post anything; status and outcome are independent.
The stated purposes are customer visibility, driving resolution suggestions to technicians, and building training material around how specific issues get fixed.

When to use / skip

Use resolutions where the client asks a question you currently can't answer from data: what actually fixed this fault, how often is it no-fault-found, which resolution correlates with a repeat visit inside thirty days. Those are good questions and free text will not answer them.

Skip them where the client has no intention of analysing outcomes. Resolutions are another field for the technician to complete, and an unused picklist on a mobile form is a small tax on every job for no return. If the honest answer to "what will you do with this data" is "nothing yet", leave it out and add it later — it's additive configuration, not architectural.

Also be sceptical when a client wants resolutions and a detailed substatus set and a completion notes field and an inspection capturing the same thing. Pick the one that the reporting actually needs. Duplicating outcome capture across four mechanisms is the fastest way to get four inconsistent answers.

Configuration decisions

The resolution list itself, and its granularity. This has the same failure modes as incident types: too coarse and it tells you nothing, too fine and technicians pick the first plausible option.
Which resolutions attach to which incident types, and whether every incident type gets a mapped set or only the high-volume ones.
Whether recording a resolution is mandatory before a job can be completed, and if so how you enforce it — business rule, mobile form logic, or process rather than platform.
Whether "no fault found" and similar non-outcomes are in the list. They should be, but the client needs to decide whether that's a resolution or a reason code.
How resolutions relate to any existing fault-code taxonomy the client already has, particularly if one exists in a legacy system or an ERP.
Who owns the list after handover, and how new resolutions get added when technicians hit something not on it.

Gotchas

Resolutions live on the work order incident. Reporting written against the work order header will miss them, and a work order with three incidents has three resolutions, not one.
Deleting a work order incident to change its incident type takes any recorded resolution with it.
Suggestions are driven by the incident-type mapping. An incident type with no associated resolutions gives the technician an empty or unfiltered list, which reads as broken.
A resolution list that grows organically becomes unusable on a phone. Long picklists on mobile are worse than long picklists on a desktop by a wide margin.
Because resolutions are independent of status, nothing stops a work order being posted with no resolution recorded. If it matters, you have to enforce it yourself.
Retiring a resolution doesn't rewrite history. Old records keep pointing at it, which is correct but confuses anyone building a report from the current active list.

Consultant notes

Ask the client to write down the three outcome questions they want answered before designing the list. If they can't produce three, that's your answer on whether to implement this.
Demo the technician's view on mobile with a realistic list length. Clients agree to forty resolutions on a whiteboard and change their minds when they see the scroll.
Configure resolutions in the same session as incident types. Doing them separately means someone has to revisit every incident type, and they won't.
Push back on making resolution mandatory in the first release. Make it visible and easy, see what the completion rate looks like after a month, then enforce if the client still wants it.
Before go-live, check the resolution mapping on your highest-volume incident types specifically. Those are the ones that generate the data anyone will ever look at.

Worth another look if resolution suggestions gain Copilot-driven behaviour or move onto the work order header.