Permit to Work at Your Site, Part 1: The Permit Request Model

Every site and every customer has its own way of getting work authorised. Some need every digital permit reviewed before work starts. Others trust their crews to issue their own. Gate Apps supports both and tailors to whatever your site and your work process need.

Moving to a digital permit-to-work system is also a chance to re-evaluate which process makes sense for your operation, given how networked most work sites are today: your own workers, main contractors and layers of subcontractors on the same ground at the same time.

Two models come up again and again when Gate Apps customers take a new system into use: the permit request model and the self-service model. Part 1 covers the permit request model and Part 2 the self-service model.

The permit request model: what it is

For sites running higher-risk work, the permit request model runs like this:

1. Request. A contractor or a worker submits a permit request: the job, the location, the people, the equipment and the time window.
2. Review. A designated authoriser checks it against site conditions, isolations and overlapping work.
3. Approval and issue. The authoriser issues the permit, often with conditions attached: a gas test before entry, a fire watch for the duration, an isolation confirmed first.
4. Execution. Work proceeds under the permit, visible and traceable on site.
5. Close-out. The contractor marks the work done and the permit is formally closed, with isolations removed and the area handed back.

Where its strength is

The strength of this model is control. It suits environments where hazards are complex or interdependent, or where regulation demands a documented sign-off chain before work begins:

• Process plants, where one job changes the risk of the next one. Simultaneous operations need somebody who sees the whole unit, see the oil, gas and chemical guide.
• Isolation and confined-space work, where a permit is only valid once a specific isolation has been verified, see the LOTO guide.
• Sites with many contractor companies, where no single crew can know what the crew on the other side of the wall is doing.

The request is the plan

Most permit processes are documented as forms. The productive ones are run as orders. On a form, the risk assessment and the approvals are collected after somebody has already decided the work is happening on Tuesday. On an order, the permit request is the plan, and Tuesday only exists once the plan is approved.

• The request carries the plan. Task, area, equipment to be isolated, hot work or confined space, who is doing it and with which competencies.
• The risk assessment belongs to the order. A job safety analysis or a last-minute check is attached to this permit, not filed somewhere else.
• Approvals happen in sequence. Issuer, area owner, operations. Each sees what the previous one saw, and each decision carries a name and a time.
• Close-out is the end of the same record. Isolations removed, area handed back, permit archived.

Time goes into waiting: a crew standing at the gate while somebody looks for the issuer, a contractor turned away because a competency certificate lives in another system, a permit re-typed because the paper copy is unreadable. A request made the day before, routed automatically and approved on a phone removes most of that waiting. The permit-to-work software guide walks through what the routing looks like in practice.

How it is configured in Gate Apps

In Gate PTW this workflow is fully configurable: who can request, who can authorise (single or multi-level), which conditions or checklists apply to which work types, and how isolations or overlapping permits get flagged. The approval chain mirrors your own team structure and site rules.

• Permit templates for the common high-risk work types, plus your own.
• Mandatory tasks per stage, so nothing is missed before work begins, during it, and at close-out.
• Competency checks attached to the permit, so a request from somebody without a valid card is caught before the authoriser spends time on it.
• A live map of every active permit, so the authoriser reviews a request against what is going on around it.

Is it the right model for your site?

Three questions settle most cases:

1. Do regulations, your customer or your own procedures require a documented sign-off before the work starts?
2. Are the hazards interdependent, so that one job changes the risk of another?
3. How many permits a day, and how many people can authorise them?

If the answers to the first two are yes, this is your model for that work type. If the third answer means the reviewer becomes the bottleneck, the site needs both models: the request model for the high-risk work, and the self-service model for the rest. Part 2 explains how that split works, and what it changed at one of the largest sites in Finland.