The Permit to work module is the written authorisation of hazardous work: who may work where, on what, until when and under which conditions — and who took responsibility for it. A permit is not a filled-in form but a route: from the draft, through issuing and handing over the site, to taking the area back, every step is recorded by a signature — with a timestamp and a name, linked into a chain. That chain is the §10.2 auditable trail: afterwards you can still show who decided what, and when.
The module is ordered separately. If you don’t see Permit to work in the menu, or the page says “The Permit to work module is not switched on”, your organisation has not switched it on yet.
Every arrow is a button in the bar at the top of the permit’s page, and every press is a signature in the chain. The bar states what the permit is waiting for (for example Waiting to be issued), who is next (It’s your turn or Next: the issuer) and since when; next to it is the button for the next step, and the rare steps (such as Cancel permit) are in the ⋮ More actions menu. A step is only active for someone who holds the right for it — everyone else sees it disabled, with the reason (“Not possible: …”).
By default the issuer cannot be the requester (unless your organisation enables One-person issue with a reason), and finishing the work takes two steps (the performing party hands the area back, the plant takes it back). Acceptance, the on-site handover, the hand-back, the “countersigner ≠ issuer” rule and the reasons for suspending and cancelling are policy switches — all ON by default; if acceptance and on-site handover are both off, issuing the permit starts the work. The lifecycle chart in Permit settings shows what is live today.
There are four main types: general work, hot work, confined-space entry and work in an explosive (Ex) zone. The type is decided by the job’s main hazard — that is what the What kind of work? field of a new permit asks. Supplementary hazards (for example hot work inside a confined space) do not get a separate permit: they go onto the same permit, as questions and the boxes those questions open. The factory default is one job = one permit. If a draft’s type does not cover the job’s main hazard, the page says so and offers to switch to the right type; after submitting, the type can no longer be switched.
Work permits
The register: every permit, with status tabs (All permits · Active · Expiring (≤2 hours) · Paused / handed back · Requests · Closed) and site, plant and type filters. The list says how many permits are shown, and the filter stays until you clear it with Clear filters (✕) — also when you come back from a permit. New permit starts in the header, next to the paper fallback Blank form ▾ dropdown.
Risk assessment
“Step 0”: you assess the job first, and the assessment tells you which permit(s) it needs and under which mandatory conditions. Your organisation’s policy decides whether it is mandatory.
Person register
The documents of workers and issuers (medical fitness, training, qualifications) with their expiry dates — the competence check works from these.
Export
The register as a table download (CSV or Excel), using the list’s filters.
Evidence
Checking every signature chain in one go, and the paper check. Scanning a printed permit’s QR code with a phone tells you without logging in whether work may proceed on it RIGHT NOW (WORK MAY PROCEED / DO NOT WORK), and whether the paper is the latest version.
Permit settings
The Policy gates (company-wide — Company — all sites — or overridden per site), the OPEREX standard tab (where your settings differ from the recommendation), the work permit templates and the risk assessment template. The default is the OPEREX recommended profile; a looser setting only saves with a reason.
What your organisation shapes in the process (templates, policy, risk assessment) and what is fixed for every permit, with a swimlane diagram: Permit to work — the process.
| Right | What it is for |
|---|---|
| ptw:view View permits | The list, the details, the signature chain, the PDF, the export and the evidence page. |
| ptw:request Request and accept a permit | The performing party: requests a permit, accepts the issued permit, acknowledges the workers, and hands the area back when the work is done. They see their own requests even without the view right. |
| ptw:issue Issue a permit | The plant’s representative: issues, hands over the site, suspends, extends, closes the working day, and finally takes the area back. |
| ptw:extend Extend and close (without issuing) | Closes the working day, extends and closes — but cannot issue a new permit. |
| ptw:approve Counter-sign a permit | The production manager’s countersignature, when the policy or the template asks for it. |
| ptw:assess Risk assessment | Creating, approving, cancelling and copying an assessment. |
| ptw:manage Manage templates and policy | The settings and the Person register — it does NOT grant the right to issue. |
| ptw:loosen_without_reason Loosen settings without a reason | A setting looser than the OPEREX recommendation saves without a reason (by default only the System administrator); the loosening is still recorded. Exception: enabling One-person issue still asks for a reason, even with this right. |
Your administrator assigns these rights to roles (in the permission matrix). If a tab or a button does not show up for you, this is the most common reason.