Permits

A permit to work is a promise made before the work starts: these are the controls, this is who is responsible, this is the window it runs in, and here is somebody senior agreeing to all three. Hot works, confined space entry, working at height, isolations, excavation near services. The paperwork exists because the alternative has killed people.

Teralo's version keeps the application, the approval, the checklists at each stage and the close-out on one record, and puts the live ones on a board anybody on site can see.

Applying for one

Choose New and pick the permit type, which decides what the rest of the form asks you. Then the work itself: where, described from the project's location tree or as free text where locations have not been set up, what the work is, and the start and end date and time.

Name the permit holder, the person who is responsible while the work is going on. That is a role rather than a formality, and it should be the person who will actually be there.

Fill in whatever the type adds. A permit type carries its own fields, which can be text, a number, a date, a set of options, a dropdown, or a required attachment, so a hot works permit can ask for the fire watch duration and a confined space permit for the gas test results without either form being cluttered with the other's questions.

Link the safety data sheets for anything being used, and any observations that are relevant. Only accepted sheets can be linked, which is one of the quieter reasons to keep that register reviewed.

Then submit it. Until you do, it is a draft and nobody has been asked for anything.

The three checklists

The part of this tool that does the most work. A permit type carries three separate checklists, and each one gates the transition it belongs to:

• The pre-start checklist must be complete before the permit goes active
• The finish checklist must be complete before the work is marked complete
• The close-out checklist must be complete before the permit is closed out

"Complete" means every item in that phase carries an answer. This is enforced when the transition is attempted rather than only greyed out on screen, so a permit cannot be walked forward from a phone with half its checks blank.

Each item can be a pass or fail, free text, a number, a date or a selection, so a checklist is not restricted to tick boxes where a reading needs recording.

Status

Nine statuses, and the sequence through the middle of them is the permit's actual life:

• Draft, being written
• Pending approval, submitted and waiting
• Approved, agreed but not yet started
• Active, pre-start checklist done and the work is under way
• Completed, work finished and the finish checklist done
• Closed out, the close-out checklist done and the record final

Three sit outside that line. Rejected comes with a comment saying why. On hold pauses an active permit and resumes it later, without moving it forward or backward. Cancelled ends a permit that is not going to happen.

Expired is calculated, not set

Expired is the odd one out, and worth knowing before you go looking for it in a filter. It is not a status anybody sets and it is not stored on the record. An approved or active permit whose end time has passed simply displays as expired, everywhere it appears.

So a permit does not quietly close itself when its window runs out. It goes on showing as an expired permit until somebody extends it, completes it or cancels it, which is the right behaviour when the question being asked is whether work is still authorised.

The public permit board

The project's public portal publishes the permit register, so anybody on site can check what is authorised today from a phone with no Teralo account and nothing to install.

It shows approved, active, on hold, completed and closed out permits, with the expired ones marked as such. Drafts, pending applications and rejected permits are not published, which is what you want: the board answers "what work is allowed here right now", not "what has anybody asked for".

It is a board rather than a form. Nobody applies for a permit through the public portal; applications come from inside Teralo.

Across a whole organisation

Permits exist at project level and at organisation level. The project register is the one you work in day to day. The organisation register is the same records rolled up across every project you have access to, with a project column, which is the view for anybody asking how many confined space entries are open across the business this week rather than on one job. See Organisation level and project level.

Permits waiting on you appear in My Items, both the ones you are approving and the ones you hold.

SettingsHost only

Tools, then Permits holds the permit types. Each type has a name, a numbering prefix that becomes the permit number (a prefix of HW gives HW-001), its custom fields, and its three checklists.

Write the types at organisation level and activate them per project. That is the difference between an organisation with one hot works permit and an organisation with eleven slightly different ones. See The tools catalogue.

The workflow binding is set for the module rather than per type, because the lifecycle is the same whatever the permit is about. Only the checklist content changes, and that lives on the type.

PermissionsHost only

• Can view permits shows the sidebar item and the register
• Can create permits allows applying for one
• Can manage permits allows approving, rejecting, cancelling, editing any permit, and configuring the tool
• Can permanently delete permits is separate and not implied by managing

Note what is not in that list: there is no separate approve permission. Approving a permit is managing permits, so anybody you give the manage permission to is an approver. On a tool where the approval is the entire safety control, that is worth being deliberate about. See How permissions work.

Editing a permit that has been sent back for revision is restricted to the organisation that submitted it, on top of the permission.

WorkflowsHost only

Submitting a permit starts its workflow, and a permit cannot be submitted until one is bound: with nothing bound, submission fails with a message pointing at tool settings. Drafts are unaffected.

The default shape approves, then runs the three checklist-gated steps: start work, complete work, close out. A manager creating a permit for their own organisation's work is approved immediately by the graph rather than having to approve their own application, which is the sensible reading of a host issuing themselves a permit.

Putting a permit on hold, resuming it and cancelling it sit outside the workflow deliberately. A hold is a pause rather than a step, so it does not advance anything and cannot be overwritten by the run.

Build variations in the workflow builder and attach them as described in Binding a workflow to a tool.