> ## Documentation Index > Fetch the complete documentation index at: https://docs.assetinfinity.ai/llms.txt > Use this file to discover all available pages before exploring further. # Work order settings > Priorities and service levels, the escalation ladder, work order types and their nesting, and resolution codes. 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](/config/work-requests): 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: | Setting | Meaning | | - | - | | **Rank** | Its place in the order. What "critical" means is "rank 1" | | **Respond within** | How long until somebody must be on it | | **Resolve within** | How long until it must be finished | | **Applies to** | Which categories or sites it is offered on, or everywhere | 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](/work/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](/work/work-order-detail#escalations-dependencies-and-closure) — which is a different, one-off act and does not touch this configuration. ## Work order types What kind of job this is. The defaults: | Type | For | | - | - | | **Preventive** | Scheduled maintenance from a plan | | **Corrective** | Fixing something found wrong | | **Breakdown** | Something has stopped | | **Inspection** | A round of checks | 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: | Setting | Meaning | | - | - | | **Default priority** | What a job of this type is raised at unless a priority rule or a person overrides it | | **Applies to** | Which categories or sites it is offered on | | **Visible to** | Which roles may raise this type, or everyone | | **Reopen window** | How long after closing a job of this type may still be reopened | | Behaviour flags | What choosing this type actually does, in a sentence each — not a checkbox labelled after its own column name | A type's **planned** flag — not a list of type codes — is what the *planned against unplanned* chart on the [Executive dashboard](/get-started/dashboards) 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](/config/assets), 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.