1. What are access events?
Access events show what happened at the gate for a booking or driver.
Each access event records things like:
How the gate was triggered (app, Get Help, visitor link, LPR, admin remote trigger, etc.)
Whether the gate opened
Whether a vehicle actually entered (at some sites)
Whether there was any misuse or manual override
They help answer questions such as:
Did the driver actually try to open the gate?
Did the gate open?
Did a car enter, or was it just a trigger?
Did an admin open the gate or change the booking passback state?
2. Where to find access events
The easiest way to troubleshoot access events is in Live View, especially when you need to look up what happened for a specific day or booking:
Log in to the Management Portal.
Go to Operations → Live View.
Find the booking or driver you want to investigate.
Look at the Access Events section/column for that booking.
You will see a list of access events, with names and colours as described below.
Access events can also be found on a user profile, or under Operations > Access Controllers > Logs.
3. How to interpret access events
Use the event name, gate, and colour to understand what happened at the gate.
Typical flow for a successful entry (most sites):
Access Requested → Gate Opened
Typical flow for a successful entry for sites with no in-ground loop after the gate.
Access Requested → Gate Opened → Vehicle Entered
Typical flow for a successful entry for sites with an in-ground loop after the gate.
If you see red or unusual events, use the table below to interpret what they mean.
4. Access event definitions and colours
Use this as a quick reference when reading events in Live View.
Event Name | What it means | Colour |
Access Requested | The driver pressed the open button in the BaseUp app (standard Bluetooth/open flow). A request was sent to the controller to open the gate. | Light Green |
Gate Opened | The controller confirmed that the gate actually opened after an access request or trigger. This is the main indicator that the gate did open for that attempt. | Solid Green |
Vehicle Entered | The gate opened and a vehicle drove over the in-ground loop/sensor, confirming entry. Only shown at sites with an in-ground loop installed after the gate. Most sites will only show “Gate Opened” as the final access event. | Dark Green |
Access Misuse | Misuse at the gate, for example a vehicle sitting on the loop too long, reversing off, or behaviour that looks like tailgating or incorrect use. | Red |
Visitor Access | A visitor opened the gate using a visitor access link (no BaseUp app required). | Pink |
App Get Help | The driver pressed Get Help in the app, and the gate was opened through that flow. This is still a successful access event, just via the help route. | Dark Blue |
Scanner Remote Trigger | Gate was triggered by a scanner-style remote trigger (single-site scanner mode). The scanner behaves similarly to a remote open. | Solid Green |
Fallback Remote Trigger | Bluetooth did not succeed, so the app automatically switched to a fallback remote open. The driver may not notice the difference; the gate still opens. | Solid Blue |
Access via building integration | Access came via the building’s own system, such as LPR or a swipe card, instead of directly from the BaseUp app. | Light Purple |
Manual Passback Update | An admin manually changed the driver’s passback state (for example, from Enter to Exit) in the system. | Grey |
Remote Open on Booking | An admin opened the gate remotely for a specific booking (Remote open on booking), usually to help a driver at the gate. | Solid Orange |
Follow-on Trigger | This gate is configured in BaseUp to auto-open when another gate is triggered. Common with roller doors (e.g., opening the entry gate also opens the roller door, so the driver doesn’t need to press Open again). | Light Blue |
5. Special notes on certain events
Vehicle Entered
Only appears at sites that have an in-ground loop installed after the gate.
Most sites will not show this event; they will just show Gate Opened as the final confirmation.
If your site does not have loops, it is normal to never see “Vehicle Entered”.
Remote Trigger and Access Requested
Remote Trigger and Access Requested events on their own are not a concern.
They simply show how the gate was opened (standard app open, Get Help/remote style, etc.).
If you see an increased number of Remote Trigger or Access Requested events, it may be worth checking, but it does not always mean something is wrong. Possible reasons include:
Drivers prefer to use Get Help / remote trigger even when Bluetooth works.
Driver phones have incorrect Bluetooth settings, so the app falls back to a remote-style open.
The hardware was temporarily offline for a short time, but still accepts access via Bluetooth. Remote trigger is not operational when the hardware is offline.
Normal behaviour changes (new users, visitors, new devices, etc.).
If you are concerned by a pattern:
Go to Operations → Access Controllers.
Check the hardware status (online/offline) for the gates in question.
If the hardware is offline, raise a support request with the Client Success team for further troubleshooting.