Electronic Permit to Work Software: How Do You Stop Two Crews Working the Same Isolation?

Why control of work breaks the moment the permit office gets busy

It is 05:40 in the permit office of a mid size refinery. Twenty two contractor supervisors are queued at the window. The isolation register is a red binder that one person controls. The area authority for the north units is signing his fourth hot work permit while a pipefitter waits to ask whether a spade off the debutaniser is still in or was pulled last Thursday. Somewhere in that queue sit two jobs that must not run together: a crew hydroblasting an exchanger bundle and a crew about to break a flange on a line draining into the same sump. Nothing in that room can see the pair.

The stack around this is familiar. Work orders live in SAP PM or IBM Maximo. Permits are paper, or a PDF form printed, signed, scanned and filed. The isolation register is the binder plus a spreadsheet that only agrees with it some of the time. Gas readings are handwritten by whoever held the detector. Some sites have bought Enablon Control of Work, Sphera Control of Work or Damstra, and use maybe half of it.

Here is the uncomfortable part. Incident investigations at plants like yours rarely find a missing rule. OSHA 1910.147 covers energy isolation, 1910.146 covers confined space entry, 1910.119 covers process safety management, and your site procedure already says the right things. What investigations find is two permits that were each individually correct, issued by different area authorities, for two jobs that shared one drain header. Paper cannot represent that relationship, so the only defence is a supervisor who happens to remember.

Problem 1: conflicts are spatial and system based, and a permit list cannot see them

A permit references an equipment tag. That is where most electronic systems stop. Real simultaneous operations conflicts are not tag against tag, they are relationship against relationship. The jobs that hurt people share a common drain, a common flare header, a vent stack, a scaffold platform above another live job, a crane radius over an operating unit, or a firewater ring main that one of the permits has depressurised.

The commercial packages model a permit to asset link and then a manual SIMOPS review meeting. That review meeting is a human reading a printed list at 06:00, which is exactly the control that failed. What you need is a site model: equipment tags grouped into systems, systems grouped into areas, areas carrying elevation and access relationships, and a rules layer that says which combinations require an additional authority or a hard stop.

What a custom build does: when the issuer opens a new permit against tag E-1204, the system already knows every other live or planned permit that touches E-1204, anything on its isolation boundary, anything on the same sump or flare sub header, and anything physically above or below it in the same structure. It shows the clash before the signature, not in a review meeting after. The rules are yours, written from your SIMOPS matrix, and editable by your HSE lead without a vendor change request. That single capability is normally why the project gets approved.

Problem 2: the isolation register is your safety spine and it is still a binder

Ask a plant manager what the highest consequence data set on site is and the honest answer is the isolation register. Which valves are shut, which spades are in, which breakers are racked out, which of those are long term isolations carried over from the last turnaround, and who is hung on each one. In a lot of plants that lives in a book, a spreadsheet and a set of numbered tags in a cabinet.

What breaks it is time. A long term isolation applied in March is still in place in September, the original applicant has left the contractor, the tag number has been reused, and the de isolation instruction references a drawing revision nobody can find. Then a second job wants a partial de isolation of the same boundary to test a pump, and the register has no concept of partial.

What a custom build does: isolation points are objects, not lines in a book. Each carries its energy source, method, applied by, verified by, tag number, drawing reference and photo. An isolation certificate groups points into a boundary. Permits hang on the boundary, and the system will not allow de isolation while any permit is hung. Long term isolations get review dates and escalate when they pass. Partial de isolation is a first class operation with its own approval, because it happens and pretending it does not is how people get hurt. The register becomes queryable, so the question of what is isolated in unit 4 right now takes two seconds instead of a walk to the permit office.

Problem 3: your approval matrix is not the vendor approval matrix

Every site has grown its own control of work standard, usually after an incident. Hot work in a classified area needs the area authority plus the fire watch nomination plus a gas test within the last 30 minutes. Confined space entry needs a rescue plan and a standby person named on the permit. Night shift permit extension is allowed for cold work only, and only by the shift superintendent. Contractor supervisors can request but never issue. Some permits need the process engineer when the job touches a relief path.

Configurable workflow engines in the big packages will get you close, then force a compromise on the last 20 percent, and the compromise is always in the direction of the vendor model. Sites then run a shadow paper process for the exceptions, which means the electronic record is incomplete, which is the worst of both worlds during an investigation.

What a custom build does: your permit types, your fields, your signature stages and your escalation rules, expressed as data rather than code so HSE can change a rule without a release. Validity windows and shift handover behave the way your standard says, not the way a Norwegian offshore operator negotiated with a vendor in 2014.

Problem 4: turnaround multiplies volume by ten and the field has no signal

Normal operation might be 40 permits a day. A major turnaround takes that to 400 or 600, with contractor crews who have never been on your site, a temporary permit office in a portacabin and three shifts. Any system that is merely acceptable at 40 falls over at 600, usually at the queue rather than in the software.

Two hard constraints shape the build. First, mobile devices inside a process unit need to be rated for the hazardous area classification, so field issue and field gas testing run on intrinsically safe tablets or handhelds, and that hardware is slower and has a smaller screen than the developer laptop the demo was built on. Second, there is often no reliable wifi at the far end of a unit, so the field app must work fully offline and reconcile later, with clear rules about what a field user is allowed to do while offline. Signing a hot work permit offline is not one of them. Recording a gas test result is.

What a custom build does: pre approval of routine permit packs before the turnaround starts, so the 06:00 queue is a collection point rather than a drafting session. Group issue for repeat jobs. Kiosk mode at the gate. A dashboard that shows the shift superintendent live permit count by area, which is the number that tells you whether you have too many people in one unit.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, the honest shape here is a first release at $70,000 to $150,000 shipping in 12 to 18 weeks. That covers permit types and workflow, the electronic isolation register, gas test capture, area and system based conflict detection and a field view. It is a system the permit office runs on from day one, not a pilot. The full platform, adding contractor competency and induction checks, turnaround surge features, offline intrinsically safe devices, work order integration and analytics, runs $180,000 to $450,000 phased over 6 to 12 months.

What pushes the number up on control of work projects specifically:

• The number of permit types and how different their rule sets are, since each is effectively its own form and workflow.
• Building the site model, meaning the tag to system to area hierarchy and the drain, flare and firewater relationships that drive conflict rules. If your P and IDs and equipment register are messy, this is discovery work and it is not optional.
• SAP PM or Maximo integration, which is a real project on its own if the work order and functional location data is inconsistent.
• Hazardous area rated hardware and offline sync, which roughly doubles the field app effort compared with a normal tablet app.
• Multi site rollout where each site insists its standard is different, which it is, so the rules layer has to be genuinely site scoped.

What keeps the number down: start with one unit, two permit types and the isolation register. That is where the risk concentrates and where the learning is.

Build versus buy, and when buying is the right answer

Buy if you are a single plant issuing under ten permits a day with one permit issuer and no turnaround larger than a few dozen contractors. Damstra and the entry tiers of the big platforms will digitise your form, and a custom build would be an expensive way to get a PDF replacement. Buy also if you are a group site being told to standardise on the corporate Enablon or Sphera instance, because fighting that is a political project and not a software one.

Build when two or more of these are true. Your SIMOPS control depends on a person remembering relationships between systems. Your isolation register is paper or a spreadsheet and you have long term isolations older than a year. You have implemented a commercial package and run a shadow paper process for the permit types it could not express. Your turnaround permit office is the bottleneck that delays the 07:00 start every morning. You operate multiple sites with genuinely different standards and one vendor configuration is being forced on all of them.

The threshold is not permit volume alone. It is whether the coordination logic between permits, isolations and areas has become the actual safety control on your site. Once it has, that logic belongs in a system you own and can change the week after an incident, not in a vendor backlog.

How to choose a developer for control of work software

Ask them to whiteboard the data model before you sign anything. A developer who has done this draws permit, isolation point, isolation certificate, tag, system, area, gas test and event log, and can explain why a permit hangs on a boundary rather than on a tag. A developer who draws forms and approvals has built an expense tool and is about to learn process safety on your budget.

Ask specifically how conflict detection works. If the answer is a report the issuer can run, they have not understood the failure mode. It must be evaluated at issue and it must consider relationships between equipment, not just matching tag numbers.

Ask what they have integrated. SAP PM functional locations and Maximo asset hierarchies are different problems. Gas detector data capture, badge and access control systems at the gate, and intrinsically safe device management are each specific. Ask for the named system and version, not a claim about integrations in general.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else. At Digital Heroes the code is yours from the first commit, and on a safety critical system you should walk away from any developer who hedges on that.