Reference · built on requestOperator by FibricSafety, security & compliance

Visitor Pre-Registration

Reads upcoming meetings and deliveries. Proposes visitor pre-registrations, host notices and screening holds before anyone arrives.

Request accessPricing ↗

About

Most visitors are already in a calendar. A meeting in Outlook or Google Calendar with an outside attendee, a delivery slot booked with the dock, a contractor visit on a shared calendar. The front desk finds out when the person is standing there.

Visitor Pre-Registration reads calendar events at the sites you name, picks out attendees from outside your domain, and proposes a pre-registration in your visitor system for each one, with the host, the arrival window and the guest type. It proposes a notice to the host the morning of the visit. Where a name matches a deny list you maintain, it proposes a screening hold for the security desk instead of a pre-registration. The desk decides.

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

  • Calendar events with attendees from outside your domain, through the Microsoft Graph event resource or the Google Calendar API Events list and watch
  • Guest events already registered, hosts, guest types and past visits per site, through the Verkada Guest endpoints
  • Guests and invites on access platforms that model them, such as Kisi guests and invites or Brivo digital invitations
  • Delivery and contractor bookings held on a shared calendar or a Google Sheet the dock maintains
  • A deny list you maintain, such as the CSV deny list the Verkada Guest endpoints accept, matched by name

Proposed actions

  • Target capability: propose a Guest event in Verkada with host, guest type, invitees and time window, for the host or front desk to approve
  • Target capability: propose a host notice in Microsoft Teams or Slack the morning of the visit, naming the visitor and the arrival window
  • Target capability: propose a screening hold for the security desk when a visitor name matches the deny list, with the calendar event attached
  • Target capability: propose a dock notice for a delivery booking, with carrier, window and receiving contact
  • Target capability: propose cancelling a pre-registration when the calendar event is cancelled or the outside attendee declines

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

What you can build

  • Register tomorrow's visitors from the calendar

    Each evening the operator reads Outlook events for the next day, finds outside attendees, and proposes one Verkada Guest event per visitor with the organizer as host. The front desk approves the list in one pass.

    With Microsoft Outlook, Verkada

  • Warn the desk before a denied name arrives

    A Google Calendar invite includes a name on the site deny list. Instead of a registration, the operator proposes a screening hold with a Slack notice to the security desk.

    With Google Workspace, Slack

  • Tell the dock what is coming

    Delivery slots kept in a Google Sheet become a morning dock notice in Teams, with each carrier, window and receiving contact, so the gate is not learning it from the driver.

    With Google Sheets, Microsoft Teams

Requirements

  • A calendar connector with read access to the mailboxes or calendars you choose, such as Microsoft Outlook through Microsoft Graph or Google Workspace
  • A visitor system with a pre-registration API, such as Verkada Guest, or an access platform that models guests, such as Kisi or Brivo
  • A messaging connector for host and desk notices, such as Microsoft Teams or Slack
  • The list of sites, the domains that count as internal, and the guest types per site
Authentication
Visitor Pre-Registration signs in nowhere. Calendars, visitor systems and messaging are read and written through the connectors you connect, and each pre-registration or notice is a proposal until a person approves it.

Limits

  • Only events with an attendee outside your domains are read. Internal meetings are never proposed for registration.
  • It does not screen against government or commercial watch lists. The deny list is the one you maintain.
  • Meeting bodies and attachments are not read. Attendee, organizer, time, location and subject are the fields used.
  • Visitor systems without a pre-registration API get a desk notice instead of a registration.

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 Visitor Pre-Registration ↗

Questions and answers

Does a pre-registration reach the visitor system without a person looking at it?
No. Each proposed registration waits for the host or front desk to approve it. You can approve a whole day's list at once, but nothing is written to the visitor system until someone does.
What happens when a meeting is moved?
The calendar connector reports the change. The operator proposes an update to the registration's time window, or a cancellation if the event is cancelled, and the host notice is reissued once the change is approved.
What does it keep about each visit?
A record per proposal: the calendar event id, the visitor and host, the registration or hold written, who approved it, and how to withdraw it. It does not keep meeting bodies or attachments.
Ask about Visitor Pre-Registration

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