Configure the maintenance policy

Work orders in the Maintenance module pass through gates (approval, start, technical completion, close). What each gate demands is decided by the policy — so the module can stay simple at a small plant and strict at a process-industry site. Every gate has three settings:

• Off — the gate does not apply and its field is not even shown on the work order;
• Warn — the gate asks, but can be overridden with a justification; the justification is recorded on the work order and in the audit trail;
• Block — the action cannot be performed without meeting the condition; the button is disabled and shows the gate’s name.

Before you start

• Permission: maintenance administration — cmms:manage.
• Where: Maintenance → Settings → Policy tab.
• Prerequisite: the Maintenance module is enabled for your organisation.

Organisation default and site override

Every switch has an organisation-level default which a site may override — but only towards stricter: a laxer site value never overrides the organisation’s stricter default. The page shows the actually effective value next to every gate.

The steps

1. Open the Maintenance → Settings → Policy tab.
2. Pick a scope: Organisation default sets the common base; Site override (with the site picker at the top) tightens one site.
3. Start from a profile: Basic (SME-friendly) sets almost everything to Warn; Strict (process industry) to Block and required fields. After Apply profile every value can be fine-tuned individually — the profile switch is audited.
4. Fine-tune per gate: every row explains what it gates and what happens on Warn/Block. An empty field means inheritance (a site inherits the organisation default; the organisation inherits the built-in default).
5. Press Save. The change is effective immediately — open work-order pages render with the new gates on the next load.

Damage and cause codes need a code table

The Damage code and Cause code at close gates work from the dictionary on the Code tables tab. If it is still empty, the “Load industrial reference set” button gives you a starter damage/cause taxonomy in one click — it never overwrites your existing codes, and everything stays renamable, extendable and archivable.

Handover and completion (the new gates in the “Execution” and “Close” groups)

The policy can also gate execution discipline — all of these are off by default; the Strict profile turns them on:

• Handover record — operations records the equipment handover (the checklist is your template: one item per line in the Handover checklist template field), maintenance accepts it, and after the work the area is handed back. When on, “Technically complete” requires a handover record. An open handover automatically appears in the shift diary (“Open handovers in the area” — with the checked preparation items) and shift close warns about it; handing the area back removes the row.
• Operational test result — the test is recorded on the work order (while in progress). A failed test opens an automatic diary event and the work order stays in progress.
• Attachment on close — a photo or PDF report on the work order; on “Required” there is no technical completion without one.
• Punch list — small unfinished items (with a type code and due date); the Open punch item at close gate can warn or block while an item is open.
• Two-step acceptance — closing needs the operations acceptance signature in addition to the maintainer’s “Technically complete”.
• Operability statement — “Technically complete” is the maintainer’s signature, operations acceptance is the other side; a PDF record of the statement can be downloaded from the work order.

Signatures — a chain that cannot be silently altered

The handover, acceptance, test, statement and operations acceptance land on the work order’s signature timeline: each signature references the previous one (with a SHA-256 digest), so nothing can be altered afterwards without detection. The work order states whether the chain is intact — or broken.

Structure: linked work orders, collectives, deadlines, contractors (new gates in the “Work-order discipline” group)

The policy can also open up the structure of work orders — these switches live in the Work-order discipline group:

• Sub / linked work orders (on by default) — from a work order’s detail you can create a child work order in one click (a sub, or “fault-finding” when the scope isn’t plannable in advance); the parent’s location/plant is inherited. The “Related work orders” box shows the parent and the children.
• Collective work order — created with the “Collective” checkbox; existing work orders can be attached to it from the detail view. The child must be on the collective’s site (other sites are rejected) and the attachment cannot form a cycle.
• Deadline change request — the performer can request a deadline change (with reason/code) on the work order, decided by the maintenance lead. For an already-expired deadline — without prior notice — the request is refused.
• Contractor registry — once on, an external contractor can be assigned to the work. Edit the registry under Settings → Contractors.
• Gatekeeping view (on by default) — the Maintenance → Gatekeeping menu lists open requests, TBD items, overdue work and deadline requests in one place, with per-row decisions. When off, the menu item is hidden.

Templates, runtime, condition, KPIs (the “Templates, condition, KPIs” group)

These switches live in the settings group Templates, condition, KPIs — each is on/off:

• Inspection-round template pack — when on, one click on an asset’s detail view loads a reference industrial inspection round (operator routine tasks with a checklist). The set is editable, never overwrites existing data, and applying it twice creates no duplicate.
• Runtime-based frequency — when on, PM tasks can take a runtime interval (instead of/besides the calendar due date), and the asset can record its cumulative runtime. The system generates a runtime work order once runtime reaches the next interval. Without a recorded runtime it does not generate — it never invents a due date. Runtime can only be written upwards (a meter does not run backwards).
• Condition thresholds — when on, a threshold can be set on an asset’s measurement field (above or below a limit). When a reading crosses the threshold, the system opens one preventive work order (a condition demand) — at most one per threshold, so no duplicate is created while the previous one is open.
• KPI pack — when on, maintenance KPIs appear on the Maintenance → Gatekeeping view (open TBD, request→decision lead time, first-time accepted, overdue, repeat repair, preventive ratio). This also requires the Analytics module and the “view analytics” permission. Where there is no data it says “no data” — not 0.

Checklist / work instruction on the work order

The work-order detail can carry structured execution steps (checklist / SOP) — six step types: sub-task (done/not), text, number, inspection (pass/fail), choice, meter reading. Adding steps is the maintenance lead’s job (cmms:wo:manage); filling them is the assigned performer’s (or the lead’s). A step can also be set to “N/A”.

The “Checklist completion required” policy (in the Execution group) gates “Technically complete”: warn can be overridden with a justification, block refuses completion until the required steps are filled. A failed inspection counts as filled — the finding is not swallowed but must be closed on the punch list, which can be gated separately.

The result

Work-order pages ask exactly what the policy prescribes: a disabled gate’s field does not appear, a warn gate shows a yellow band with a justification field, and a block gate shows a disabled button carrying the gate’s name. Justifications for overridden warn gates remain traceable on the work order and in the audit trail.

If you get stuck

• A button is disabled and shows a gate name — the blocking condition is unmet (e.g. the work order has no functional location, or the mandatory damage code is missing). Supply the data or loosen the policy.
• You cannot see the Policy tab — the settings need the cmms:manage permission.
• A site-level loosening “does not apply” — that is by design: a site can only tighten.