Permit Check is an operator for the paperwork before hazardous work starts. HSE guidance on permit-to-work systems (HSG250) treats training, competence standards, work planning, and monitoring as parts of one system, and 29 CFR 1910.147 requires the authorized employee to verify isolation before work begins.
This operator reads the permit request from MaintainX or IBM Maximo Manage, the asset's isolation status, the day's access events from Brivo Access or LenelS2 OnGuard, and each worker's training records in Deputy or BambooHR. It proposes issue with every check listed, or refusal with the gaps named. The issuing authority decides and signs. The operator never touches a controller or a door.
This is a reference listing. It documents what Fibric would read from Permit Check 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-to-work requests and the work orders behind them: MaintainX work orders with blockedByWorkPermitReason, or Maximo work orders read from mxapiwodetail
Isolation state as recorded: the asset's OFFLINE status in MaintainX, its status on mxapiasset in Maximo, and the isolation steps ticked on the work order
Who is on site and where: Brivo access events by site and event_type, or OnGuard logged events such as access granted and access denied
Contractor and employee credentials: Brivo users with their groups and suspended state, OnGuard cardholders, visitors, and badges
Training records with expiry: Deputy TrainingRecord rows with Module, ExpiryDate, and Active, or BambooHR training types with a completion date and renewal frequency
Permits already open on the same asset or area, so two jobs are not issued against one isolation
Proposed actions
Target capability: propose issuing the permit, listing each check passed: isolation recorded, worker on site with a valid badge, training current, no clashing permit
Target capability: propose refusing the permit with the gaps named: isolation not recorded, badge not seen at the gate, training expired on a given date
Target capability: propose a MaintainX work order comment or a Maximo work order field update that records the check result against the permit
Target capability: propose a list of workers whose training blocks the permit, with the expiry date from Deputy or BambooHR, for the supervisor
Target capability: propose adding a worker to the Brivo group for the permit's area through PUT /groups/{groupId}/users/{userId}, and removing them when it closes
Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.
What you can build
Check a MaintainX permit against Brivo and Deputy
A work order blocked by a work permit is read from MaintainX. The operator confirms the asset is OFFLINE, the contractor badged in at the site in Brivo, and their Deputy training is Active, then proposes issue or refusal.
For a Maximo work order in a permit workflow, the operator matches the assigned workers to BambooHR training records. A required course past its renewal date produces a proposed refusal naming the person and the date.
OnGuard logged events show whether each named worker's badge was granted access at the area reader today. Workers not seen are listed as gaps on the proposed refusal, with the last event time.
A CMMS that holds the permit or the work order it hangs on: MaintainX work permits, or IBM Maximo Manage work orders
An access control connector with logged access events and cardholder records: Brivo Access or LenelS2 OnGuard
A source of training records with expiry dates: Deputy training records or BambooHR training
A mapping from permit type to the isolation, training, and area rules it must satisfy, set in the operator's configuration
Authentication
Each check runs through the connectors already bound, using the CMMS, access control, and HR credentials they hold; the operator holds none itself.
Limits
It checks records, not the plant. Verifying that isolation and deenergization were done is the authorized employee's duty under 29 CFR 1910.147(d)(6), and stays theirs
Isolation is read as the CMMS records it. A lock hung but not logged reads as missing, and the refusal says so
The permit is signed by a person. MaintainX documents signing through POST /workPermits/{id}/sign with a signer's name; the operator never calls it
Access events show a badge, not a person. A shared or borrowed badge passes the site check
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.
The issue or the refusal. Both show every check with its source: the isolation record, the access event, the training record and its expiry. The issuing authority approves, overrides a check with a reason, or dismisses. Signing the permit is done by that person in the CMMS, not by the operator.
What record stays with the permit?
The permit request, each check and the record it was judged on, the result proposed, the person who approved or overrode it and when, and the comment or field written to the work order. Overrides are kept with their reason.
Does it ever isolate equipment or open a door?
No. It reads isolation status and access events. It never writes to a controller, changes a door schedule, or releases a door. The one access change it can propose is adding a worker to a Brivo group, which you approve and which is reversed from the receipt.
Ask about Permit Check
Ask about the capabilities and requirements in this listing.
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