Duress Response is an operator for the moment a panic button is pressed. It reads the alarm as your security platform raises it, with the device that raised it, the site and partition, and whether the alarm is silent. It pulls the camera still nearest that device at the trigger time, the last badge event at the nearest door, and the last uplink from a LoRaWAN button.
It puts these beside each other so a person can confirm the press, then proposes the call chain your plan names, a notice to the security channel, and an incident record with every artifact attached. A person approves each step. It never dials, releases a door, or locks one on its own, and a silent alarm stays silent.
This is a reference listing. It documents what Fibric would read from Duress Response 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
Alarms raised by a panic or duress trigger in Verkada, with the device type, site, partition, trigger time, and whether the alarm is silent
Alarm and event records from Genetec Security Center or Milestone XProtect where a duress input is wired into the platform
The camera still nearest the triggering device at the trigger time, and a link to footage from that moment
Badge events at the doors nearest the device, so the record shows who was last through them
Uplinks from LoRaWAN panic buttons through your network server, with the gateway that heard each one
The response level set for the alarm, and the resolved event when the platform clears it
Proposed actions
Target capability: propose the call chain from your plan, one outbound call at a time through Amazon Connect or Twilio, each for your approval
Target capability: propose a notice to the security channel in Slack or Microsoft Teams with the still, the door, and the device name
Target capability: propose a page to the on-duty responder through PagerDuty or xMatters, carrying the alarm identifier
Target capability: propose an incident record that attaches the alarm, the still, the footage link, the badge event, and every approval
Target capability: propose closing the record once the platform reports the alarm resolved and a person confirms the scene is clear
Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.
What you can build
Confirm a silent duress press before anyone calls
A cashier presses a wireless panic button and Verkada raises a silent alarm. The operator proposes a Slack notice with the nearest camera still and the last door badge, then the first call. A person approves each.
A LoRaWAN button in a plant room uplinks a press. The operator proposes calls through Amazon Connect in the order your plan lists, one at a time, and a page to the duty officer through PagerDuty.
Leave one incident record instead of five screenshots
Alarm, still, footage link, badge event, calls placed, and every approval land in one record when Genetec Security Center raises a duress event. The record closes when a person confirms the scene is clear.
One access control or video connector that raises panic or duress alarms, such as Verkada, Genetec Security Center, or Milestone XProtect
A camera and door map naming which camera and which door sit nearest each button
One voice connector, Amazon Connect or Twilio, and one messaging connector: Slack, Microsoft Teams, PagerDuty, or xMatters
A written call chain: who is called, in what order, and what the person answering should hear
A LoRaWAN Network connector if your buttons are LoRaWAN devices rather than inputs on the alarm panel
Authentication
It acts through the API keys, webhook secrets, and calling credentials your security, sensor, voice, and messaging connectors already hold. It is issued none of its own.
Limits
It confirms a press with evidence. It does not decide that an alarm is false, and it never cancels a monitoring dispatch.
The still is the frame nearest the trigger time. Where retention or a camera outage leaves a gap, the record says so.
Outbound calls are paced by your voice platform's own limits. A long chain takes longer than a short one.
It works from your button-to-camera map. A button not on the map is proposed with the alarm alone, without a still or a door event.
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.
Each call, each notice, each page, and the incident record. The approver sees the alarm, the still, the door event, and the exact number or channel the step would use. Approve, edit, or dismiss each one. Nothing is dialed or posted until then.
What record is left after an alarm?
One incident record per alarm. It holds the alarm identifier, the device, the still, the footage link, the badge event, every call and notice sent, who approved each, and when the platform resolved the alarm. Each step keeps a receipt: what was sent, why, and how to undo it.
Does it ever lock a door, cancel an alarm, or call the police on its own?
No. It reads alarms and evidence. Calls and notices go out only after a person approves them. It never releases or locks a door, never resolves an alarm in the platform, and never contacts a monitoring center or the police. Those stay with your plan and your people.
Ask about Duress Response
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