Reference · built on requestOperator by FibricSafety, security & compliance

Door Held Open

Sorts held-open and forced-door alarms by door, time, and camera view and proposes a guard dispatch, schedule exception, or hardware ticket.

Request accessPricing ↗

About

Door Held Open is an operator job for the alarms an access platform raises when a door stays open past its timer or opens without a credential. It reads door_held_open and door_forced_open events from Verkada, lock.held_open and lock.forced_open from Kisi, alarm events from Avigilon Alta, and Door Contact held open and forced open alarms from Genea, each with the door and the time. It reads the door's schedule, so a door propped during a delivery window reads differently from one forced at night, and it pulls the camera clip for that door and minute where the platform links one.

For each alarm it proposes one of three things: a guard dispatch notice, a schedule exception for a door held open at the same time every day, or a hardware ticket for a closer, strike, or contact that keeps failing. You choose, and you approve.

This is a reference listing. It documents what Fibric would read from Door Held Open 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

  • door_held_open, door_forced_open, and door_tamper events from Verkada through the v2 Get Events endpoint, filtered by device_ids and site_ids
  • lock.held_open, lock.forced_open, and lock.closed events from Kisi, and which readers have held_open_alarm_enabled
  • Alarm events from Avigilon Alta through Get alarm events, with the entry, the site, and linked cameras
  • Door Contact forced open and held open alarm categories from Genea, and access events by door and date range
  • Door schedules and exceptions: Verkada Door Exception Calendars, Brivo schedules, and the current state of an Avigilon Alta entry
  • The camera clip for the door and minute: the cameras of an entry in Avigilon Alta, or a per-camera video link from Kisi
  • Open work orders in MaintainX or UpKeep against that door, so a known-bad closer does not raise a second ticket

Proposed actions

  • Target capability: propose a guard dispatch notice in Microsoft Teams or Slack, or an SMS through Twilio, naming the door, time, and clip
  • Target capability: propose a timed schedule override for a door held open at a recurring time, through Avigilon Alta setTempState or a Verkada door exception
  • Target capability: propose a hardware work order in MaintainX or UpKeep for a door whose closer, strike, or contact keeps alarming
  • Target capability: propose a weekly list of doors ranked by alarm count and hour of day, for the security lead to review

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

What you can build

  • Send a guard to a forced door with the clip

    A door_forced_open event from Verkada outside the door's schedule becomes a Teams notice for the guard on duty, with the door, the time, and a link to the camera clip.

    With Verkada, Microsoft Teams

  • Stop a loading-dock door alarming every morning

    Kisi raises lock.held_open on the same dock door at the same hour each weekday. The operator proposes a schedule change with an end date, posted to Slack for the site lead to approve.

    With Kisi, Slack

  • Ticket a closer that keeps failing

    Held-open alarms on one Avigilon Alta entry across several days, with no schedule pattern, become one MaintainX work order for the door hardware, linked to the alarm events.

    With Avigilon Alta, MaintainX

  • Text the on-call guard from Genea alarms

    A Door Contact forced open alarm from Genea after hours becomes an SMS through Twilio to the on-call guard, and a Slack thread that holds the reply.

    With Genea Access Control, Twilio, Slack

Requirements

  • One access control connector that raises held-open and forced-door events: Verkada, Kisi, Avigilon Alta, Genea, or Brivo
  • One messaging connector for dispatch notices: Microsoft Teams, Slack, or Twilio for SMS
  • One maintenance connector for hardware tickets: MaintainX or UpKeep
  • The doors in scope and the guard roster, set in the operator's configuration
Authentication
Reads alarms and schedules through the access platform connector's API account, and writes notices, overrides, and work orders through the credentials of those connectors; it carries none of its own.

Limits

  • It sorts alarms; it does not decide whether a forced door is a break-in. A person reads the clip and chooses the response
  • A schedule override is proposed only where the platform's API allows one, and it always carries an end time
  • Clips are attached only where the platform links a camera to the door. Otherwise the notice carries the door and time alone
  • It never releases, locks, or blocks a door on its own, and it never silences an alarm

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 Door Held Open ↗

Questions and answers

What does a person approve for each alarm?
Each proposal: the alarm, the door's schedule at that time, the clip if one is linked, and the response the operator suggests. You pick dispatch, schedule exception, or ticket, or dismiss it. Nothing is sent or changed until then.
What record does an alarm leave?
A receipt for every alarm handled: the event, the response chosen, who approved it, what was sent or written, and how to reverse a schedule change. Dismissed alarms stay on the record, so a door that cries wolf is visible.
Will it ever open or lock a door?
No. It reads events and schedules. A schedule override is proposed with an end time and applied only after approval. It never sends a door release, a lock command, or a lockdown, and it never acknowledges alarms in the platform.
Ask about Door Held Open

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