Issuing, handing over and closing a permit

The issuer turns the submitted request into a permit, the performing party accepts it, the issuer hands over the site — and when the work is done, the performing party hands the area back and the plant takes it back. Every step is a button in the bar at the top of the permit’s page, and every press is a signature in the chain: who, when, with what justification.

Before you start

• Permission: issuing, handing over the site, suspending and taking back belong to the issuer — ptw:issue. Accepting, acknowledging the workers and handing the area back belong to the performing party — ptw:request. Countersigning needs ptw:approve; closing the working day, extending and closing without the issue right need ptw:extend.
• Prerequisite: a permit in the Requested status (you find it on the list’s Requests tab) — or, with one-person issue, your own draft.

The steps follow the policy

By default the issuer cannot be the requester: you cannot issue your own request, even with the issue right — unless your organisation has enabled One-person issue with a reason (see below). Finishing the work takes two steps by default: the performing party hands the area back, the plant takes it back. Acceptance, the on-site handover, the hand-back, the “countersigner cannot be the issuer” rule, and whether suspending, cancelling, extending an expired permit and an extraordinary close need a reason — these are all switches in the policy’s Steps, signatures, reasons group, all ON by default (in the OPEREX recommended profile too). At least one of acceptance and on-site handover always stays. The lifecycle chart in Permit settings shows what is live today.

Steps

The status bar at the top of a valid permit. A button only opens that step’s row below the bar — you sign with the row’s own button; rare steps are in the ⋮ More actions menu.

1. Open the permit and look it over. The bar at the top of the page states what the permit is waiting for (here: Waiting to be issued), who is next (It’s your turn or Next: …) and since when. Next to it is the button for the next step; the rare steps (Cancel permit, Extraordinary close) and the steps you are not allowed (disabled, with the reason) are in the ⋮ More actions menu. The Simultaneous operations (SIMOPS) card says whether it found another permit overlapping in time in the plant (and on the location branch) — and which scope it searched.

   The issuer sees the issue gates in advance in the same bar (already on the draft), in two groups:

   • Block — while such an item stands, the permit cannot be issued (the Issue permit button is grey);
   • Warn — the issue goes through, but the Justification field is mandatory and the reason goes into the signature chain. If Passing a warning gate needs a reason is OFF in the policy, the list says so: it goes through without a reason, and the warning still goes into the chain.

   The items are written in plain language: for a missing competence, for example, you see the name of the document kind, not an internal code.

2. Issue the permit. Click Issue permit in the bar. In the row that opens in the bar:

   • if your organisation asks for it, tick “I declare that I am on site and have checked the conditions”;
   • if your organisation asks for two-factor confirmation, type the code from your authenticator app into the Two-factor code field;
   • the Justification is mandatory when a gate on the warn level is not satisfied (the reason goes into the chain) — the field then gets an asterisk, with the warning gates listed below it.

   Then click the row’s Issue permit button. The status: Issued.

3. Countersignature — if required. The OPEREX recommended profile asks for the production lead’s countersignature in production areas. If the policy or the template asks for the production lead’s countersignature (for example because the work affects the energy supply of production), the bar says Waiting for the production countersignature, and the approver signs with the Countersign button. By default the approver cannot be the issuer (the policy switch The countersigner cannot be the issuer). The status: Countersigned.

4. Acknowledging the workers. In the Workers table, the performing party records row by row, with the Worker acknowledgement button, that the worker has read the permit. If the template makes it mandatory, every worker must be acknowledged before acceptance.

5. Acceptance. The performing party takes the permit over with I accept the permit. The status: Accepted. If the work supervisor has no account (for example a contractor), a user with an account can record the step on their behalf: in the Who is signing? row they choose on their behalf, enter the name and whether the supervisor signed the paper copy by hand or declared in person, in their presence, and attest to it. The chain records both the name and the manner, and the recorder stays under their own name; for a paper-signed acceptance, keep the hand-signed copy. If you issued the permit, accepting it in your own name asks for a justification by default. If Supervisor acceptance is OFF in the policy, this step is skipped.

6. Handing over the site. The issuer hands over the area with Hand over the site (activate); in the row they can enter the name of the work supervisor taking over the site. The status: Active — work may only happen in this status. If Issuer on-site handover is OFF in the policy, the acceptance makes the permit Active straight away.

7. While the work runs.

   • Suspend (a reason is mandatory by default) → Suspended; the work restarts with Resume.
   • Close the working day → Working day closed: the isolations stay in place, and the next day the work continues with Extend (new working day) — you enter the end of the new validity (for an expired permit, by default a reason as well).
   • Confirm shift handover: a member of the incoming shift with the issue right confirms that the work may continue.

8. Handing the area back. When the work is done, the performing party hands the area back with Hand back the area; all three questions must be answered: Is the work finished? · Is the equipment safe and are the isolations removed? · Has production taken the area back? The status: Handed back. If hand-back is switched off in the policy, this step is skipped and the issuer answers the template’s questions at closing. The hand-back can also be recorded on the work supervisor’s behalf (the same way as the acceptance).

9. Taking the area back (closing). The issuer closes with Take back the area (close). The Reason for closing: Completed · Continued with a new permit · Extraordinary close (this needs a note by default — the policy can switch that off). The status: Closed.

What cannot be undone

Cancel permit (in the ⋮ More actions menu) is only available before the site is handed over, and it is final: the permit goes to Cancelled — with a reason by default. The system does not erase the fact that a site was handed over — from there the route is the hand-back and the close.

A complete route in the signature chain. The “Recomputed in your browser” line is your own device’s computation, not the server’s claim.

If it worked

After every successful step, a notice states the new status: “Done — the permit is now: …”. If you let a warn-level gate through with a justification, a second notice lists what: “Warnings (allowed with a justification): …”. A new row appears on the Signature chain card with the step’s name, your name and the time, and the top of the card says: “The chain is intact: … signature(s).”

Common problems

What you see	Why	What to do
The button is disabled: “Not possible: you do not have permission for this step.”	Your role does not have the right for this step.	Ask your administrator, or the step is done by someone who has the right.
“Not possible: you have the right, but this step is only available on your OWN request and only before it is issued.”	With the request right you can only cancel your own request that has not been issued yet.	Cancelling an issued permit is up to the issuer.
“Not possible: another issuer must issue your own request (one-person issue is not enabled at this site)”	You submitted the request, and one-person issue is switched off.	Another colleague with the issue right issues it — or your administrator enables one-person issue with a reason.
“You cannot issue your own request (the issuer must not be the requester).”	The issue failed on the server for the same reason (for example the switch was turned off meanwhile).	As above.
“One-person issue is not enabled at this site (Settings → Policy gates → Issue).”	The switch was turned off during Issue without a requester.	Submit it as a request and let another issuer issue it — or ask the administrator for the switch.
“Not possible: The template’s mandatory preparation tasks go to the diary with the request step …”	The template has mandatory preparation tasks and the policy requires them before issue — that cannot be met without a requester.	Submit it as a request.
“Blocked by the policy: This permit type does not cover the work’s main hazard — …” (with the hazard’s name)	This type does not cover the main hazard marked by the questions (for example hot work).	On a draft, switch the type; a submitted request must be cancelled and resubmitted with the right type.
“The issuer cannot countersign their own issue.”	You issued it, and The countersigner cannot be the issuer is ON.	Another colleague with the countersign right countersigns it.
“Blocked by the policy: …”	A gate on the block level is not satisfied (for example an unanswered mandatory row, a missing document, a preparation task not done).	Fix what is listed, and try again.
“This action requires a justification — the reason goes into the signature chain.”	A gate on the warn level is not satisfied.	Write in the Justification field why you proceed anyway.
“The permit’s time window has expired — it cannot be made active.”	The end of the validity has already passed.	Extend it with a new validity, or hand the site back.
“All three hand-back questions must be answered.”	One of the questions was left unanswered.	Answer all three (“No” is an answer too).
“The step was not carried out”, with a “Reload to see the current version” button	Since the page loaded, the permit was moved on or changed elsewhere — you would have signed a version you had not seen.	Reload, look it over, and start the step again.

Worth knowing

• The daily cut-off time (if one is set for the site) is handled by the system: at the cut-off it closes the working day of the active permits by itself (the signer is then SYSTEM), and expiry is determined by the system too. The shift diary warns about the permits still open before the cut-off.
• The diary shows the permit too. In the plant’s diary the Open permits block lists the plant’s permits; the shift-handover confirmation is available from there as well.
• When extended, the number gets a /2, /3 suffix, and the Extensions table lists the extensions.
• An event under the permit: if an event in the diary is linked to the permit, the permit’s page says: “An event occurred under this permit: consider suspending it. The system does not do this automatically.”
• Issue without a requester (one-person issue). The policy switch One-person issue (no requester) is OFF by default, in every profile; it can only be switched on with a one-time reason of at least 10 characters. When it is on, the main step on your OWN draft is Issue without a requester: for a request that arrived on paper or verbally, the issuer issues the permit in one step. You can then also issue your own ALREADY SUBMITTED request with the normal Issue permit button. When it is off, the step does not appear at all, and issuing your own request is disabled, with the reason. If the template has mandatory preparation tasks and the policy requires them before issue, Issue without a requester is disabled with the reason — submit it as a request instead. The requester’s name and how the request arrived (on paper, verbally, by phone) can be given but are optional. Every issue gate still applies (on-site statement, two-factor code, mandatory rows). The signature chain gets two rows (Request — one-person issue, recorded by the issuer and Issue), and the issued permit’s paper states ONE-PERSON ISSUE (no requester) with the policy reason.
• The signature chain: since 2026-09-28 every new signature’s fingerprint also covers the previous signature’s fingerprint, its own sequence number and the signing time — so a signing time or an order changed afterwards can be detected too.

Related

Request a permitFrom the draft to the submitted request.

Preparation tasks and conditionsTasks sent to the diary before and during the permit.

Policy gatesWhat blocks and what warns at issue — per site.

Paper check and evidenceWhat the signature chain proves, and how you check the paper.