run.events Access Control

What happens the second you open it

The first screen of the run.events Access Control app presents a QR code scanner. This is not a login screen or a dashboard. It is a camera viewfinder with a single button. The app expects a configuration QR code. Without this code, the app does nothing. It cannot be used. There is no manual entry option. No email login. No password. Just a scanner. This design is intentional. The app is built for event staff who need to initialize multiple devices quickly. The configuration QR code contains all the event data. It tells the app which event, which check-in stations, and which access levels to use. Scanning the code pulls down the entire event setup. The app then becomes a fully functional check-in and access control tool.

Once initialized, the main interface changes. It shows a list of attendees or a session list, depending on the configuration. The default view is a grid of attendee names or a search bar. Staff can search for an attendee by name or email. Tapping a name brings up the attendee's details. This includes their ticket type, session access, and a check-in button. The check-in button triggers the camera again. This time it scans the attendee's badge QR code. The app confirms the match and marks the attendee as checked in. The entire flow is scanner-first. It is built for speed.

How badge scanning for networking and lead retrieval work together

The QR code on each attendee badge serves two distinct purposes. For attendees, scanning another person's badge initiates a networking connection. The app sends a connection request. Both parties can then chat and share profiles within the app. This is a social feature. It encourages interaction. For sponsors, the same QR code scan captures lead data. The sponsor's app instance, configured with lead retrieval permissions, records the attendee's contact information. The sponsor can then sort and qualify the lead immediately. This dual-use of the same QR code is efficient but creates a potential conflict. An attendee might scan a sponsor's badge thinking it is for networking, but the sponsor's app treats it as a lead capture. The app does not clearly distinguish these two modes. The only difference is the role assigned to the user during initialization.

This workflow is powerful for event organizers. It eliminates the need for separate networking and lead retrieval systems. However, it requires careful configuration. The organizer must assign the correct roles to each device. A device initialized for check-in staff cannot scan for leads. A device initialized for sponsors cannot check in attendees. The configuration QR code enforces these roles. The app does not allow role switching without re-scanning a new configuration code. This is a limitation. It means staff cannot switch between roles during an event. Each device is locked to a single function. For large events with multiple stations, this is manageable. For smaller events with limited staff, it can be restrictive.

The real-world performance and the QR code reader issue

The app's performance is generally stable. The version 1.2.0 update specifically focused on improving stability and performance. However, a known issue exists with the QR code reader. The built-in scanner does not work well from certain angles or in overexposed lighting. A standard Android QR reader app can scan the same code instantly, but the run.events app fails. This is a critical flaw for an app that relies entirely on QR scanning. Event environments are often brightly lit. Badges are held at various angles. Staff need to scan quickly. The app's scanner struggles in these conditions. There is no manual entry option as a fallback. If the scanner fails, the staff member cannot proceed. They must reposition the badge or move to a different lighting condition. This adds friction to the check-in process.

The app does not cache attendee data locally. It requires a network connection to pull event data and to record check-ins. This is a design choice that ensures real-time synchronization. However, it introduces a dependency on network stability. If the venue Wi-Fi is unreliable, the app becomes slow or unusable. The check-in under 8 seconds claim assumes optimal network conditions. In practice, network latency can increase this time significantly. The app does not provide offline mode. This is a notable limitation for large venues with poor connectivity. The official documentation mentions offline-capable kiosks, but this appears to apply to the kiosk hardware, not the mobile app itself. The mobile app requires an active internet connection for all functions.

The app's integration with Google Wallet is seamless. Attendees can add their tickets to Google Wallet. This provides an offline backup. Even without internet, the ticket QR code is accessible. The app can scan this code from the wallet. This mitigates some of the network dependency issues. However, the check-in confirmation still requires a network connection. The app must send the check-in data to the server. If the network is down, the check-in cannot be recorded. This creates a gap. The attendee is physically present, but the system does not reflect their check-in. The app does not queue check-ins for later sync. This is a significant operational risk.

The specific technical detail that defines the configuration QR code

The configuration QR code is generated in the run.events dashboard. It contains a unique configuration key. This key includes the event ID, the device role (check-in, host, sponsor, kiosk), and access permissions. The app decodes this key and uses it to fetch the full event configuration from the run.events servers. The QR code does not contain the full event data. It only contains a reference. This keeps the QR code small and scannable. However, it means the app must have network access to download the configuration. Without internet, the configuration QR code is useless. The app cannot initialize. This is a deliberate design. It ensures that the app always uses the latest event data. But it also means the app cannot function in offline scenarios. The Kiosk App, which is a separate version, may support offline operation. The Access Control app, however, is online-only.