DocsBeta

Access control

Access control

Configure relays, booking and geofence rules, review access logs, and maintain relation-specific exceptions.

Last updated 2026-03-28

The Access control module manages relays that can be triggered through Aerolync. Relays represent physical access points such as gates, doors, hangars, and other controlled entry points at your facility. Pilots trigger these relays directly from the Pilot App Home screen when they need to gain entry.

How access control works

Aerolync evaluates several conditions each time a pilot triggers a relay. Depending on how you configure the relay, the system may check the pilot's location (geofence), whether they hold a valid booking, or whether a person-specific exception applies. If all conditions pass, the relay opens. If any condition fails, the attempt is denied and logged.

Where to start

  1. Open Access control from the admin platform.
  2. Review the relay list to find the relay you want to work with.
  3. Open the relay to access its detail tabs: access log, configuration, and access exceptions.

What the module covers

  • Relay list -- all relays available to your organisation, with their active status
  • Access log -- a chronological record of every relay trigger attempt, including successes and failures
  • Configuration -- the rules that determine when and how a relay can be triggered
  • Access exceptions -- person-specific overrides that bypass the normal rule set

Understanding relay rules versus exceptions

Most access decisions are made through the relay's configuration: its active status, geofence boundaries, booking requirements, and linked resources. These rules apply equally to everyone.

Access exceptions are different. An exception targets a specific person (relation) and overrides the normal rules entirely. A person with a "granted" exception will always be allowed through, regardless of other settings. A person with a "blocked" exception will always be denied.

Because exceptions bypass all other logic, they should be used sparingly and reviewed regularly. A temporary exception that is never removed becomes a permanent gap in your access policy.

Documentation pages

Each page in this section matches a tab or view within the Access control module:

Common tasks

  • A pilot reports they cannot open a gate -- start with the Access log to find the failed attempt and read the error message, then check Configuration to verify the relay is active and the pilot meets all conditions.
  • You need to give someone permanent hangar access -- open Access exceptions for the relevant relay and add a "granted" exception for that person.
  • A relay should only work for pilots with active bookings -- open Configuration and enable the valid booking requirement.
  • You want to restrict access to pilots who are physically nearby -- open Configuration and enable the geofence with appropriate coordinates and distance.

Good practice

  • Start every investigation from the relay list and work inward through the tabs
  • Use the access log as your first stop for troubleshooting
  • Keep relay names descriptive and operationally specific so they are easy to identify in the list and in the Pilot App
  • Review access exceptions at regular intervals to ensure temporary overrides have not become permanent
  • Test configuration changes by verifying a trigger attempt in the access log after saving