Visitors and kiosk check-in

What the visitors board shows

The visitors board sits under Visitors in the workspace navigation. It is one page with three lists, all drawn from the same visitor records: who is on site now, who is expected today, and an audit log of recent visits.

All three lists are filtered by location. Pick a site in the location filter and every list narrows to that building at once, so a busy multi-site workspace can look at one reception desk at a time. Your choice is remembered as the workspace location preference and carries over to other pages that read the same setting.

On site now holds guests who have checked in and have not checked out. Expected today holds pre-registrations whose expected time falls inside today, measured in the workspace timezone. The audit log is a history rather than a snapshot, so guests currently on site appear in it as well.

• On site now: guests with an active check-in.
• Expected today: pre-registrations due today that have not arrived yet.
• Audit log: the last 100 check-ins in the current filter, whether or not the guest has since left.

The on-site cards

Each card carries the guest's name, their company where one is recorded (otherwise the site name, which is what a kiosk check-in shows), the host they are visiting, and the time they checked in. Times are shown in the workspace timezone rather than the server's clock.

The card also carries a badge field, and it reads Pending. Nothing in the visitor record tracks a physical badge being handed over, so there is no state here that would make it read Issued.

When nobody is on site the list says so plainly rather than showing an empty frame.

Expected today

The expected list is a single column ordered by arrival time, earliest first. Each row carries the guest's name, their host, the arrival time, and an Invited badge.

Every row on this list is a pre-registration that has not arrived yet. The board does not show a separate confirmed state, so Invited is the badge you will see.

The audit log

The audit log is a table of the last 100 visits with a check-in time, newest first. Its columns are the date and time, the guest, the host, the facility, and the duration.

Duration runs from check-in to check-out. For a guest who is still on site it counts up to now, so the number grows while the visit is open. Pressing the date column reverses the order of the rows already on the page rather than fetching a different set.

The host column names the person being visited, falling back to their email address when the profile has no name. An arrival where the visitor typed a name at the kiosk instead of picking someone shows that typed name with (not found) after it, so a verified match is never confused with free text. If there is neither a host nor a typed name the column reads Unassigned, which after the current check-in flow should only be older history.

The web check-in kiosk

The kiosk is a public page at /check-in, meant to be opened once on a tablet or screen at reception and left there. The visitor fills in the form, and the arrival appears on the visitors board for the building the link names.

Each site has its own link. You will find it on the site's edit page under Locations, headed Visitor check-in link for that site. The link carries your workspace and the site, and the site part is an opaque code rather than an id, so the address names a building without listing your sites.

Copy link puts the address on the clipboard and Open loads it. Replace link issues a new code immediately: every tablet and every printed code still using the old link stops working until it is reopened on the new one, so treat replacement as a deliberate recovery step.

The address needs a building only when there is more than one to choose from. A workspace with exactly one live site can use a link that names the workspace alone, and the page resolves that site. A workspace with several sites must name the building on the link: without it the page refuses to check anyone in and says which building to copy a link for.

Older links carried a raw site id instead of the site code. Those are refused with a sentence saying the link is out of date and where to copy a current one. A site code that is not recognised, including one that has been replaced on purpose, gets its own sentence naming the same cure, so a visitor never sees a blank error.

What a visitor does at the kiosk

The form asks for the visitor's full name, which is required, an optional email address, the purpose of the visit, and who they are visiting.

Who they are visiting is a search rather than a full list. It starts looking after three characters and shows up to 10 matches, each with the person's company underneath their name so two people with the same first name can be told apart. A host is required: the check-in is how that person is told the visitor has arrived, so an arrival with nobody named is not recorded.

If the visitor cannot find their host, they can choose I cannot find who I am visiting and type a name or a company instead, up to 120 characters. That path still records the arrival and routes the announcement to reception rather than to an individual.

A successful check-in shows a short confirmation and clears itself after a few seconds, ready for the next person.

Who appears in the kiosk list

The search is deliberately narrower than the workspace. It offers that building's companies plus your own team at every site, and members who hid themselves from kiosk search are excluded. Only active members are selectable, so invited and removed members do not resurface.

Each site also has a Require an exact name match setting, off by default. Switched on, a visitor only finds someone by typing their whole name as it is stored, which turns away guests who use a first name or a shortened form. Turn it on only if reception can handle the visitors it will turn away.

Someone who does not want their name searchable can hide themselves from kiosk search on their own profile, and a company admin can set the same switch for a person from the members list. Hiding does not stop that person's guests checking in: the typed-name path above exists so a hidden host still gets their visitor announced to reception.

How a check-in reaches the host

When the visitor names a host, that person is notified straight away on two channels: an in-app notification and an email with the subject Your guest has arrived, naming the visitor. Both channels are controlled by the Visitor arrived event in notification settings. A tenant's own setting wins over the operator's, and where neither has been set the default applies, which is both channels on.

When the visitor uses the typed-name path there is no profile to notify, so the arrival goes to reception instead: an in-app notification to every member of your team, and an email to the site's own notification address if one is set, otherwise to the operator's notification address. The confirmation on the kiosk screen tells the visitor that reception has been told they are here and who they are looking for, rather than that the person has been messaged.

Notification is best effort throughout. A delivery problem is logged and never fails the check-in, so the visitor is not left stranded by a misconfigured inbox.

Kiosk devices

Settings has a Kiosk devices page, open to host admins. It lists each registered check-in device with its label, its site, its status, and when it was last seen, and it never displays device credentials.

Revoking a device removes its access immediately. Use it when a tablet is replaced or lost; staff have to register the device again before it can reconnect.

Frequently asked