Visitor Invites and Host Lookup
Use the Visitors portal to pre-register guests, notify hosts, and control what visitors must complete before they arrive. Invites, visit history, and kiosk configuration all live here — not on Admin.
Creating an invite
From Invites (or the invite form on the dashboard):
- Choose the kiosk / location the guest will visit.
- Enter visitor name and email.
- Select a host — typeahead search suggests employees from your connected directory.
- Set date and time (and optional end time).
- Optionally set purpose of visit, visitor company, and subject line.
When you send the invite, the system:
- Creates a visit record with a unique invite code
- Sends email with the code, QR code, badge verification link, and (when configured) Apple Wallet / Google Wallet links
- Includes address and directions from the kiosk when configured — see below
- Sends a pre-check-in email if the kiosk has requirements the guest has not yet completed
- Sends a calendar invite (ICS) after requirements are satisfied, or immediately when none apply
Directions in invite emails
Before guests arrive, they need to know how to find your office and how to enter the building. Configure that once per kiosk:
- Location address — street address for maps and calendar location
- Directions / instructions — free text such as which entrance to use, parking, reception desk location, or elevator instructions
Set these on the Visitors portal under Kiosks, or in Settings → Visitor Instructions on the native iPad app. See Customization — visitor directions.
When you create an invite, Include directions in invitation email appears if the kiosk has directions saved — checked by default. Guests then see your instructions in the invitation, pre-check-in, reminder, and calendar emails (and on wallet passes when enabled). Uncheck the box for a one-off invite if you do not want directions on that message.
Guests check in at the kiosk with their invite code or QR code. See Check-in flows.
Proposing a new visit time
When a guest counter-proposes a time on a calendar invite (standard ICS update from their calendar app), Meeting Room 365 processes the inbound reply and emails the host to approve or decline. No extra setup is required — it works from the ICS event attached to the invite email.
Gmail and Outlook have been tested as guest calendar clients. After approval, both parties receive updated calendar events.
Host directory lookup
Host fields can search your organization directory when staff create invites on the Visitors portal or when walk-in guests pick a host at the kiosk.
| Provider | Supported for host lookup |
|---|---|
| Microsoft 365 | Yes — Microsoft Graph |
| Google Workspace | Yes — Google People directory |
| Exchange (EWS) | No — not supported for visitor host lookup |
The first time directory search needs broader read access, an admin may be prompted to upgrade directory permissions through a one-time Microsoft or Google consent flow. SSO sign-in for staff uses the same Microsoft or Google identity — there is no separate SSO fee.
Staff invite creation (Visitors portal)
When receptionists or admins create an invite, host typeahead runs in an authenticated staff session on visitors.meetingroom365.com. The caller is already signed in with Microsoft or Google org access — this is a staff tool, not a public kiosk surface.
Walk-in host lookup at the kiosk
Enable directory search on the kiosk so walk-in guests can find their host during sign-in. On the native iPad app, directory search is a first-class security feature — not just autocomplete convenience.
Directory search security (native iPad kiosk)
The Visitor Check-in Kiosk native iPad app treats host lookup as a visitor-facing operation that must not leak your employee directory. The design keeps directory traffic and anti-phishing controls on the tablet.
On-device directory boundary
When a walk-in searches for a host on the native iPad kiosk:
- The tablet queries Microsoft Graph or Google People directly — using the Microsoft or Google credentials established when the kiosk was signed in.
- Directory search traffic does not route through Meeting Room 365 servers for the kiosk lookup path. The connection stays inside the tablet's security boundary.
- After the visitor confirms a host, only the host name (and internal host identifier needed for notifications) travels with the check-in record. Email addresses and phone numbers are not shown to the visitor during search or selection.
Host email is captured internally when a directory match is confirmed. It is used only after check-in succeeds — to notify the host that their visitor has arrived (see Notifications). The kiosk UI never surfaces email or mobile contact info to guests browsing the directory.
What visitors see (and do not see)
| Shown on the kiosk | Hidden from visitors |
|---|---|
| Employee display name (mode-dependent — see below) | Email address |
| Optional job title, department, or office location as context | Phone numbers |
| A checkmark when a match is verified | Full directory listings without a deliberate match |
Visitors must confirm a specific person — free-text host names alone are not accepted when directory search is required.
Anti-enumeration search modes
Configure how walk-in host lookup behaves under Settings → Directory Search on the iPad. Four modes balance convenience against the risk of someone standing at your tablet typing common names to fish for employee identities:
| Mode | Behavior |
|---|---|
| Standard Autocomplete | Dropdown of matches after a minimum character threshold (default 3, configurable up to 8). Visitor must tap a result to confirm. |
| Common Name Filtering | Like autocomplete, but suppresses results for common single first names (for example John, Sarah, Michael) until the visitor adds more characters — typically a last name. Requires a higher minimum (4+ characters). |
| Verified Entry | No dropdown. Visitor types a full name, email, or work phone; the app validates an exact match in the background and shows a checkmark. Nothing is revealed unless the entry matches precisely. |
| Ghost Text | Inline completion with the untyped portion of the name obscured. After selection, the visitor sees only what they typed — the rest of the name stays hidden. Email is captured silently for notifications. |
Additional safeguards across modes:
- Minimum character count before any search runs (configurable 3–8; higher values narrow results).
- Prefix-based matching — queries match the start of a name, not arbitrary substrings.
- Small result sets — the UI shows a short list (up to five suggestions), not pages of employees.
- Confirmed selection required — walk-in check-in does not complete with an unverified host guess when directory search is enabled.
For high-traffic lobbies worried about directory phishing, Common Name Filtering or Verified Entry are the strongest defaults.
Simpler visitor sign-in flow
The simpler visitor sign-in flow (Meeting Room 365 app or browser) supports host directory assist when enabled, but does not offer the native iPad app's full Directory Search settings panel. For the detailed on-tablet security boundary and anti-enumeration modes above, use the Visitor Check-in Kiosk native app on iPad.
Hosts are stored on the visit record by name and email. At check-in, the host may receive a direct arrival email — separate from area channels (Teams, Slack, or shared inbox) that stream every arrival (see Notifications).
Approval workflows
Enable Require approval before sending invitations on a kiosk when non-admin staff should not send invites directly.
| Role | Behavior |
|---|---|
| Admin | Invites send immediately |
| Non-admin | Invite enters pending approval until an admin approves or denies |
Approved invites follow the normal email and pre-check-in flow. Denied invites do not notify the guest.
Purpose of visit
When purpose of visit is enabled on a kiosk, the invite form and kiosk check-in include a picker (for example: Interview, Delivery, Meeting, Contractor).
The selected purpose branches the check-in flow. Each purpose can define its own complete path — visitor rules, primary NDA, additional document to sign, visitor photo, custom form fields, and checkbox attestations (for example confirming insurance was submitted for staff verification). Invites created with a purpose send guests down the matching branch at pre-check-in and at the kiosk. See Encrypted document vault for guidance on PII and file uploads.
See Customization — branching check-in flows.
Frequent visitor passes
For guests who visit often, toggle Frequent Visitor on the invite form instead of a single-day invite.
- Staff set an expiry date for the pass.
- The visitor receives email with a QR code and instructions.
- Return visits use the pass at the kiosk until expiry — no new invite per trip.
- Check-in still runs configured requirements when applicable.
Frequent visitor passes suit contractors, regular vendors, and campus partners — not employees (they do not replace building access control systems).
Pre-visit requirements
Invites tie into the same requirement engine as the kiosk. If the kiosk requires rules, NDA, photo, custom fields, or uploads, the guest receives a pre-check-in link to finish online.
Visit statuses you will see on the dashboard include:
| Status | Meaning |
|---|---|
| Invited | Invite sent; no requirements or not yet started |
| Pending approval | Awaiting admin approval |
| Pending check-in | Requirements incomplete |
| Ready | Pre-check-in complete; guest expected |
| Checked in | Signed in at kiosk or reception |
| Signed out | Explicitly signed out |
| Auto checked out | Still checked in after 24 hours without sign-out |
| Expired / cancelled | Past date or invite removed |
Badge verification (QR in email)
Every invite email includes a QR code linking to a public badge verification page. Any employee can scan it on a phone to confirm:
- Visitor name and photo (when captured)
- Host and visit time
- Purpose of visit
No app install required. The page is date-gated to the visit window so old codes are not useful on the wrong day.
Staff access and SSO
Sign in to the Visitors portal with Microsoft or Google — the same SSO included in your location subscription. Users see organizations they belong to; invite and kiosk access respects org membership.
Receptionists and office managers should use visitors.meetingroom365.com, not Admin, for daily work. Admin remains for billing and creating the kiosk display key. See Visitor Management overview.
Supported / not supported
| Supported | Not supported |
|---|---|
| Invite creation with calendar ICS, QR, and wallet links | Exchange (EWS) directory for host autocomplete |
| Microsoft 365 and Google Workspace host search | Cronofy or non-M365/Google directory backends |
| Optional admin approval before send | In-room video manual join (Meeting Room TV product) |
| Purpose of visit with per-purpose requirements | Webex / Zoom join from visitor kiosk |
| Frequent visitor passes with expiry | |
| Pre-check-in email wizard | |
| Badge verification QR in email | |
| Microsoft and Google SSO (included) |
Best fit for
- Reception teams that pre-register expected guests and want hosts notified automatically
- Microsoft 365 or Google shops that want real employee directory pickers, not free-text host names
- Governed invite flows where managers must approve visitor requests before email goes out
- Campuses with repeat contractors using frequent-visitor passes
Frequently asked questions
Where do I create invites?
visitors.meetingroom365.com — not Admin. Admin creates the kiosk display key and handles billing.
Why doesn't host search find everyone?
Directory search needs appropriate Microsoft 365 or Google Workspace permissions. An admin may need to complete a one-time directory upgrade consent. Exchange-only tenants cannot use directory lookup for hosts.
Can visitors fish for employee names at the kiosk?
The native iPad app is built to prevent that. Directory queries run on the tablet (not through Meeting Room 365 servers), email and phone are never shown during search, and you can choose Common Name Filtering or Verified Entry modes to block casual name enumeration. See Directory search security (native iPad kiosk).
Is host email exposed on the kiosk screen?
No. Email is resolved internally when a host is confirmed and used only to send arrival notifications after check-in. Visitors see names (and optionally title/department/location) — not contact details.
Can I invite without an email address?
Visitor email is strongly recommended — it delivers the invite code, pre-check-in link, and wallet passes. Walk-ins at the kiosk can cover guests without prior email.
What happens when I delete an invite?
The guest receives a cancellation email and the calendar event is cancelled (ICS METHOD:CANCEL).
Can visitors propose a new time by email?
Yes. When a guest counter-proposes via their calendar app (ICS), the host receives an approval email. Gmail and Outlook have been tested. No tenant setup required.
Do invites cost extra?
No. Invites, pre-check-in, wallet passes, and SSO are included in the per-location price.
How do visitors get building entry instructions?
Configure address and directions / instructions on the kiosk. They are included in invite-related emails by default (invitation, pre-check-in, reminder, and calendar description). Use directions for prose like "Use the south lobby entrance and check in at the front desk." See Customization.
Related
- Visitor Management overview
- Check-in flows — kiosk paths for invited guests
- Notifications — area channels vs host arrival email
- Badges and wallet passes — QR, wallet, and printed badges