SMP 365 Permit to Work

What is SMP 365 Permit to Work?

SMP 365 Permit to Work brings permit requests, work conditions, independent authorisation, isolation evidence, revalidation and handback into a connected work-control record. It is intended for teams coordinating work where the scope, location, people and conditions must be understood before work can be authorised. The purpose is not simply to replace a paper form with a screen. It is to make the relationship between the request, its supporting checks and the decision to proceed easier to follow.

A permit record supports the approved site process. It does not itself establish that a workplace is safe, grant a person competence or replace the judgement of an authorised permit issuer.

Start with a clear scope and work conditions

A useful request explains what work is proposed, where it will happen and what is outside its scope. During implementation, agree which permit types your operation needs, which supporting assessments apply and what information the reviewer must see. An equipment identifier, work location and description should tell a consistent story rather than leave the issuer to reconstruct it from separate emails.

Use a representative maintenance activity during the demonstration. Review how the request and control checks are presented together, and whether the proposed record captures the conditions your own procedure requires without burdening every permit with irrelevant fields.

Separate the request from independent authorisation

The person requesting work and the person authorised to approve it have different responsibilities. SMP 365 includes independent authorisation in the permit workflow so the decision is considered separately from preparing the request. Your implementation should define who may request, review, authorise and accept a permit, including arrangements when the usual issuer is unavailable.

Ask to walk through an incomplete request as well as a successful one. The review should make missing evidence and unresolved conditions clear. Do not interpret a completed form, a status label or an email notification as permission to begin work outside the approved authorisation process.

Keep control checks, isolation and the work party in view

The product interface separates permits, control checks, isolation, gas tests and the work party. That distinction matters: supporting evidence should retain its own context rather than become an unexplained tick against the main permit. For example, a recorded test needs to be understood in relation to the relevant work, conditions and competent person. The software record is evidence of what was recorded, not a substitute for the actual check.

For work involving another team or contractor, agree how their participation and responsibilities will be represented. Confirm which connections to other SMP 365 modules are included in your deployment instead of assuming that every module shares data automatically.

Treat revalidation and handback as decisions

Conditions can change after a permit is issued. The revalidation area provides a place to consider the permit again against the work as it now stands. Your site procedure should determine which changes, interruptions or handovers require review and who may authorise any continuation. Do not carry yesterday’s assumptions into a new work period simply because a record remains open.

Handback is a separate point of accountability. Demonstrate how the work status and outstanding conditions are presented to the person accepting the handback. Closing an administrative record must not be confused with confirming that equipment is ready for return to service.

Plan a rollout around the people using permits

Start with the permit process your supervisors and work teams actually use. Bring current forms, authorisation roles and examples of returned or interrupted work to the implementation discussion. Agree how existing open permits will be handled at cutover so there is no uncertainty over which record governs the work.

For a Microsoft 365 deployment, confirm identity, access, document locations and the approved device experience with your IT team. Test the full request-to-handback journey on the devices used in the field. Network availability, offline expectations and any connection to maintenance systems should be explicit requirements, not assumed capabilities.

Permit to Work questions