Reference · built on requestOperator by FibricSafety, security & compliance

Hot Work Permit

Matches hot-work permits to detector isolations, work orders, and fire watch assignments, and proposes the permit checklist and its closure.

Request accessPricing ↗

About

Hot Work Permit is an operator job for welding, cutting, grinding, and other work that makes sparks inside a building. It reads permit requests from the form or ticket you use, in Jira Service Management, ServiceNow, or a Smartsheet, with the area, start, and end. It reads the work order behind the permit in IBM Maximo, MaintainX, or Fiix. It reads the fire detection points for that area from Desigo CC or Honeywell EBI, so it can see whether a detector is isolated, and it reads who is rostered as fire watch in Deputy.

It proposes the checklist the permit issuer signs, flags a permit whose detectors are still isolated past its end, and proposes closure once the fire watch period has ended and the points are back in service. OSHA 1910.252 asks for a written permit and a fire watch that continues after the work stops; the operator keeps those times.

This is a reference listing. It documents what Fibric would read from Hot Work Permit and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Permit requests and their fields in Jira Service Management, ServiceNow, or Smartsheet rows: area, start, end, requester, and issuer
  • The work order behind each permit: mxapiwodetail in IBM Maximo, /workorders in MaintainX, or WorkOrder records in Fiix, with status and assigned crew
  • Fire detection point state for the area from Siemens Desigo CC or Honeywell EBI, including isolation, disable, or test states as the platform exposes them
  • Fire watch assignments as Deputy roster entries or a named person on the permit, with their start and end
  • Permit and work order events: a status change on the ticket, a work order closed, a roster change on the fire watch shift

Proposed actions

  • Target capability: propose the permit checklist to the issuer in Microsoft Teams or Slack: area inspected, combustibles cleared, extinguisher present, fire watch named, detectors noted
  • Target capability: propose a permit hold when the work order is unapproved, no fire watch is rostered, or a detector is isolated without permit cover
  • Target capability: propose closing the permit and work order once the end time plus fire watch period has passed and detectors read in service
  • Target capability: propose an overdue notice when the permit end time has passed and a detector in the area is still isolated

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Run permits out of Jira Service Management

    A permit request in Jira Service Management is matched to its MaintainX work order and the Desigo CC points for the area. The issuer gets the checklist in Teams and approves it there.

    With Jira Service Management, MaintainX, Siemens Desigo CC, Microsoft Teams

  • Hold a permit with no fire watch

    A ServiceNow permit whose start is an hour away and whose fire watch shift in Deputy is empty gets a proposed hold and a Slack notice to the issuer.

    With ServiceNow, Deputy, Slack

  • Catch a detector left isolated

    After the permit end plus the fire watch period, a Honeywell EBI point for the area still reads isolated. The operator proposes an overdue notice in Teams and keeps the Maximo work order open.

    With Honeywell EBI, IBM Maximo Manage, Microsoft Teams

Requirements

  • One work and ticket connector holding permit requests: Jira Service Management, ServiceNow, or Smartsheet
  • One maintenance connector for the work order: IBM Maximo, MaintainX, or Fiix
  • One building platform connector that exposes fire detection point state: Siemens Desigo CC or Honeywell EBI
  • One messaging connector for the issuer and fire watch: Microsoft Teams or Slack; Deputy if fire watch is rostered there
Authentication
Reads tickets, work orders, points, and rosters through the connectors you bind, and posts checklists and closures through those connectors' own credentials; it holds none of its own.

Limits

  • It never isolates, disables, or restores a detector, and it never acknowledges a fire alarm. Those actions stay with the fire system operator
  • Detector isolation is read only where the building platform exposes it. A panel with no supervisory link shows nothing, and the checklist says so
  • It checks that the permit's fields, work order, fire watch, and points line up. It does not inspect the area; the issuer does
  • Fire watch duration is your permit's rule. OSHA 1910.252 sets a half-hour minimum after the work; the operator applies the value you configure

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Hot Work Permit ↗

Questions and answers

What does the permit issuer approve?
The issuer approves the checklist, any hold, and the closure. Each shows the permit, the work order, the detector states read, and the fire watch. Approve, edit, or decline. The operator does not issue a permit; the issuer does.
What is in the permit file afterwards?
One receipt per permit: the request, the work order, detector states at start and close, the fire watch and their times, each approval with a name, and the closure. It is the permit file, kept with the ticket.
Does it touch the fire system?
No. It reads point states from the building platform. It never isolates or restores a detector and never silences an alarm. Where a detector must be isolated for the work, a person does it and the operator records when.
Ask about Hot Work Permit

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy