The Access exceptions tab manages person-specific overrides for a relay. An exception bypasses the normal access rules defined in Configuration and applies directly to one person (relation) on one relay.
How exceptions work
Each exception has two parts:
| Field | Description |
|---|---|
| Relation | The specific person the exception applies to. |
| Exception type | Either "always granted" or "always blocked". |
| Exception type | Effect |
|---|---|
| Always granted | The person can trigger the relay regardless of geofence, booking requirements, or other conditions. The relay must still be active. |
| Always blocked | The person cannot trigger the relay under any circumstances, even if they meet all other conditions. |
Warning
Exceptions override all other conditions. This makes them powerful but also potentially dangerous if left unchecked. Review exceptions regularly.
When to use exceptions
Exceptions are appropriate in situations such as:
- Permanent access for staff -- a maintenance technician who always needs hangar access, regardless of bookings
- Permanent access for management -- an airfield manager who should be able to open any gate at any time
- Temporary block -- a person whose access needs to be revoked immediately while an investigation or administrative process is underway
- Special arrangements -- a visiting pilot who needs temporary access outside normal rules
Important
Exceptions are not a substitute for correct configuration. If most pilots need access under certain conditions, set those conditions in Configuration rather than adding exceptions for each person individually.
How to add an exception
- Open the relay from the Relay list.
- Go to the Access exceptions tab.
- Add a new exception.
- Select the relation (person) the exception should apply to.
- Choose the exception type: "always granted" or "always blocked".
- Save the exception.
- Verify the result by checking the Access log after the person's next trigger attempt.
How to remove an exception
- Open the relay from the Relay list.
- Go to the Access exceptions tab.
- Find the exception for the person you want to update.
- Remove the exception.
- Save. The person will now be subject to the normal relay rules defined in Configuration.
How to review all exceptions for a relay
- Open the relay from the Relay list.
- Go to the Access exceptions tab.
- Review the full list of active exceptions.
- For each exception, confirm that the override is still necessary and appropriate.
- Remove any exceptions that are no longer needed.
Common tasks
- Grant someone permanent access -- add an "always granted" exception for that person on the relevant relay.
- Block someone immediately -- add an "always blocked" exception. This takes effect on the next trigger attempt.
- A temporary exception is no longer needed -- remove the exception so the person returns to normal access rules.
- Audit who has special access -- open the Access exceptions tab and review the full list.
Important considerations
Note
Exceptions are per-relay and per-person. If a person needs an exception on multiple relays, you must add it separately on each relay.
- An "always granted" exception does not override the relay's active status. If the relay is turned off in Configuration, no one can trigger it, including people with granted exceptions.
- Exceptions created as temporary solutions can easily become permanent if they are not reviewed. Schedule regular reviews to catch stale exceptions.
- When a person leaves the organisation or changes role, check whether they have any access exceptions that should be removed.
Good practice
Tip
Review exceptions at least monthly to ensure temporary overrides have not become permanent gaps in your access control.
- Keep exceptions rare. Every exception is a deviation from your standard access policy. If you find yourself adding many exceptions, reconsider whether the relay's base configuration should be adjusted instead.
- Review exceptions regularly -- at least monthly -- to ensure temporary overrides have not become permanent gaps in your access control.
- Document the reason for each exception outside of Aerolync (for example, in a shared operational log) so that other administrators understand why the exception exists.
- When blocking a person, communicate the block to relevant team members so they can handle any operational impact.
- After removing an exception, verify through the Access log that the person's access now follows the expected normal rules.