Skip to main content
What a job may be classified as, and how fast each rung of the priority ladder is answered. Request intake — where a reported fault comes from — is configured separately, under work request settings: a planner sets this screen, whoever runs the front door sets that one.

​
Priorities and service levels

A priority is a rung on a ladder, which is why they are edited together rather than as separate records — this screen shows the whole ladder so you can see a rung that promises a faster answer than something ranked more urgent above it, and flags it. Each priority carries: Response and resolution are the service level. Changing a time here changes the promise on work raised from now on; a job already open keeps the deadline it was given, because the SLA clock is stamped when the job is raised, not read from this table afterwards.
Ranks are what sorting and the Critical view use. Renaming “Critical” to “P1” changes the label everywhere and breaks nothing.
The clock pauses in on-hold states and stops at Completed. See the lifecycle.

​
Priority rules

A priority can also be filled in automatically, rather than picked by hand: a rule says that a job raised at a given site, against a given asset category, of a given type, gets a given priority. A rule on a category also covers everything beneath it. Somebody can still override it when raising the job — a rule is a default, not a lock.

​
Escalation ladder

Behind the work.escalations module. How a job that has missed its resolution target is escalated the longer it keeps running late — each rung is a length of time past due and how loudly it is announced when it gets there, so Urgent may climb in half an hour where Routine has a day.
This ladder does not say who hears a rung. That is a notification subscription, configured under Settings → Notifications on the “A work order was escalated” event, keyed to the severity a rung is announced as. A tenant with no escalation module still has priorities and service levels; what it does not have is anything that climbs on its own.
This is the automatic ladder. A person can also escalate one job by hand, from inside the job itself — see manual escalation — which is a different, one-off act and does not touch this configuration.

​
Work order types

What kind of job this is. The defaults: A type can be filed under another type — Electrical under Corrective, say — so the list reads as a tree rather than a flat set of codes, and appears nested wherever types are offered. Each type also carries:
A type’s planned flag — not a list of type codes — is what the planned against unplanned chart on the Executive dashboard counts, so adding your own type is counted correctly without a change anywhere else.
Edit in grid opens every type in a spreadsheet-style editor, for correcting several at once rather than one form at a time.

​
Resolution codes

What was actually done, chosen when a job is closed: replaced, repaired, adjusted, cleaned, no fault found. Resolution codes are worth taking seriously. No fault found appearing repeatedly on one machine is a real signal, and only exists as a signal if people record it. A code nobody has ever chosen is flagged — a list nobody uses is a list that gets picked from at random.

​
What used to be here

Work order categories are not configured on this screen. A job classifies by the same category tree the equipment does, so that tree is administered once, under asset settings, and this screen only reads it to offer “applies to” scoping on a priority or a type.

​
Adding to any of these lists

Each section has its own New. Entries can be deactivated rather than deleted, which keeps historical records readable — a job closed against a resolution code you no longer offer still shows what it was closed as.