Reference · built on requestOperator by FibricSafety, security & compliance

Tailgate Review

Pairs badge reads with camera person counts at controlled doors and proposes an incident record or a notice to the badge holder.

Request accessPricing ↗

About

Tailgate Review is an operator job for the door that opened once and let two people through. It reads each access-granted event with its credential and time from the access platform, and the person count the camera on that door reported for the same seconds: people counts and line-crossing counts from Verkada, threshold-crossing counts from Rhombus, or zone entry events from Camera Vision on an RTSP stream. Where the platform already raises door_tailgating or lock.tailgate, it reads that too.

When the count exceeds the reads, it proposes an incident record in Jira or ServiceNow with the clip, or a notice to the badge holder whose read let the second person in. A security lead approves either. It never names the second person; it counts them.

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

  • Access granted events by door: door_granted from Verkada, /events/access filtered by site in Brivo, and lock.opened in Kisi, with credential and time
  • People counts and line-crossing counts for a camera and time window from Verkada: Get People/Vehicle Counts and Get Occupancy Trend Data
  • Threshold-crossing counts and people-count events from Rhombus through getThresholdCrossingCounts and getMostRecentPeopleCountEvents
  • Zone entry and exit transitions per configured line from Camera Vision on an RTSP stream, timestamped at the edge
  • Tailgating the platform already flags: door_tailgating from Verkada and lock.tailgate from Kisi, so the operator agrees or disagrees with a count
  • Open incidents in Jira or ServiceNow for the same door and day, so one door with a broken sensor is one incident

Proposed actions

  • Target capability: propose an incident record in Jira or ServiceNow with the door, time, badge read, count, and a link to the clip
  • Target capability: propose a badge-holder notice in Microsoft Teams or by SendGrid email, with the door and time a second person followed them
  • Target capability: propose a weekly ranking of doors by tailgate rate and hour, so the security lead can decide where a turnstile pays
  • Target capability: propose closing the incident once the security lead marks it reviewed, with the outcome noted

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

What you can build

  • Review a Verkada tailgate with the clip

    A door_granted event and a line-crossing count of two in the same window become a Jira incident with the clip, and a Teams notice to the badge holder, for the security lead to send.

    With Verkada, Jira, Microsoft Teams

  • Count with Rhombus behind a Brivo door

    Brivo /events/access reads are paired with Rhombus threshold-crossing counts on the same door. A count above the reads becomes a ServiceNow incident linked to the Rhombus clip.

    With Brivo Access, Rhombus, ServiceNow

  • Count on an RTSP camera you already own

    Zone entry events from Camera Vision on an existing RTSP camera are paired with Kisi lock.opened events. The badge holder gets an email through SendGrid; repeat doors go on the weekly ranking.

    With Camera Vision (RTSP), Kisi, Twilio SendGrid

Requirements

  • One access control connector with per-door granted events: Verkada, Brivo, or Kisi
  • One source of person counts on the same doors: Verkada occupancy trends, Rhombus threshold crossings, or Camera Vision on an RTSP stream
  • One work and ticket connector for incidents: Jira or ServiceNow
  • A map from each door to the camera and counting line that watches it, set once in the operator's configuration
Authentication
Reads access events and counts through the access and video connectors' API keys, and writes incidents and notices through the ticketing and messaging connectors; it keeps no credentials of its own.

Limits

  • A count is an estimate. Two people crossing close together can read as one; a cart can read as a person. The clip settles it
  • Counts need a camera line placed at the door. A wide lobby camera with no line gives no count
  • It does not identify the second person. Notices go to the badge holder whose read opened the door
  • Timing between platforms is by clock. Doors and cameras with unsynchronised clocks produce mismatches that a person must resolve

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 Tailgate Review ↗

Questions and answers

What does the security lead approve?
Each incident and each notice. The security lead sees the read, the count, the clip, and the text, then files, edits, or dismisses it. A notice to a badge holder is never sent without that approval.
What is kept for each tailgate event?
A receipt per event: the badge read, the count and its source, the clip link, the decision, who made it, and what was written to the ticketing system. Dismissed events are kept, so a sensor that over-counts shows up as a pattern.
Does it identify the person who tailgated?
No. It compares a count to a read and names only the badge holder whose credential opened the door. It does not run face recognition and does not enrol anyone; the clip is reviewed by a person.
Ask about Tailgate Review

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