AccessCORE Visitor

Under My Visitors, employees see the visits they host or cover as a delegate and invite visitors. Saving the site, visit type, date and time, and each visitor’s name, email, and language sends every visitor a guidance email with a link to the visitor portal.

Visits are grouped on tabs by approval stage, and opening one shows each visitor’s arrival state, check-in time, and check-in point. When several people come together, one is the lead visitor, and approval starts once the lead visitor has pre-registered.

A visit the host creates directly skips the host step of the approval line. A host who will be away names a delegate for a period; the host’s visits then appear in the delegate’s list, and the delegate can invite visitors on the host’s behalf and is recorded as the inviter.

Arrivals lists, in order of arrival, the visitors who confirmed their arrival at the kiosk or in the portal and now wait for the desk. Each card shows why it is held, the host, the purpose, the arrival channel, and how identity was checked, and the selected visitor’s progress and approvals open in a side panel.

When the visitor is ready, the desk confirms the arrival and picks the card to hand over, or leaves it blank to draw one from the site’s card pool. Outstanding steps such as agreements or training can be completed at the desk’s discretion with a recorded reason, and a site at capacity also needs an explicit over-capacity approval.

Check-in applies the visit type’s access level and the visit period to the visitor card, and extending a stay extends the access period to the new end time. Walk-in applications are reviewed here too, either sent on to approval or rejected.

The visitors screen manages visitor profiles and their visit history. Profiles are created automatically when visitors are entered on a visit, so only people who should be on file in advance, such as contractors, are registered here directly.

Duplicate profiles for the same person are merged, moving the visit history, agreements, training, and passkeys to the profile that remains. Corrections to name, phone, or company requested in the portal are approved or rejected by staff, and the visitor sees the reason for a rejection.

When a visitor asks to be deleted, their identifying data is erased: names and contact details go, while visit records and statistics remain. Profiles past their retention period are erased by the system every day, and a profile with visit history can only be erased, never deleted.

Visit types set, for each purpose, the approval line, required agreements and training, how cards are issued, which check-in channels are allowed, and which personal details are collected. Type names are entered per language, with an icon for the selection cards in the portal and on the kiosk.

By default the host approves first and the security approver second, or the steps can be arranged explicitly from host, security, and named approver. Types with no one to meet, such as deliveries, have no host step, and each type also decides on escorts, contractor compliance, and whether portal and walk-in requests are allowed.

Cards come from the site pool, are issued per visit, or are not issued at all, and separate access levels are set for the expected and checked-in stages. Changes apply to visits registered afterwards, and a warning appears when a type uses a security step but its site has no security approver.

Visitors open the portal from their guidance email and complete their details, agreements, and training step by step. No account or password is needed; the link alone is enough to prepare that visit.

The details step asks for name, email, phone, company, nationality, and the language for emails, together with consent to the collection and use of personal data. The fields depend on the visit type, and anything the visitor should know in advance, such as an escort or collecting a card, is shown alongside.

Once everything is done, the portal shows the approval status and how to confirm arrival on the day. It runs in the browser without installation, and what visitors enter is used directly for review and check-in, so staff never retype it.

The lobby kiosk is a tablet app that confirms arrivals for expected visitors and takes walk-in applications. The standby screen shows how many visitors are expected today and how many are on site, and visitors start by choosing arrival check-in or a visit application.

When the site is busy or at capacity, the standby screen says so, and where walk-ins are not accepted it points visitors to their invitation link or the desk instead. The language can be switched, and a progress bar shows the steps that remain.

The kiosk runs in landscape only, and on Android tablets it uses screen pinning so no other app can be opened. After a period without input it asks whether to continue, and without an answer it deletes what was entered, photos included, and returns to standby.

Visitor cards are access cards in the access control system, and the visit type defines the access levels for the expected and checked-in stages. Check-in applies the visit period and the checked-in level to the card; check-out withdraws the access and returns the card to the pool.

Pooled cards have their cardholders and credentials synced to the controllers in advance, and only their access and period change, so visitors can pass as soon as they check in. Actions that change access, such as check-in, card, vehicle, and recurring-grant updates, request a sync run as soon as they are saved, so they reach the controllers right away.

Controllers block the card themselves once the visit’s last day has passed, even without the server; within that day, the overstay check-out withdraws access. Door events recorded by the controllers are linked to the actual visitor through the card’s assignment period.