---
title: Visitor Invites and Host Lookup
summary: Pre-register visitors, host directory search, approval workflows, frequent-visitor passes, and pre-visit check-in requirements.
lastReviewed: 2026-06-10
products:
  - visitor-management
status: published
---

# Visitor Invites and Host Lookup

Use the [Visitors portal](https://visitors.meetingroom365.com) 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):

1. Choose the **kiosk / location** the guest will visit.
2. Enter visitor **name** and **email**.
3. Select a **host** — typeahead search suggests employees from your connected directory.
4. Set **date and time** (and optional end time).
5. 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](https://visitors.meetingroom365.com) under **Kiosks**, or in **Settings → Visitor Instructions** on the native iPad app. See [Customization — visitor directions](./customization.md#visitor-directions-and-instructions).

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](./check-in-flows.md).

## 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](https://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:

1. The tablet queries **Microsoft Graph** or **Google People** **directly** — using the Microsoft or Google credentials established when the kiosk was signed in.
2. 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.
3. 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](./notifications.md)). 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](./notifications.md)).

## 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](./customization.md#encrypted-document-vault) for guidance on PII and file uploads.

See [Customization — branching check-in flows](./customization.md#branching-check-in-flows-by-purpose-of-visit).

## 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](./index.md).

## 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](https://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)](#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](./customization.md#visitor-directions-and-instructions).

## Related

- [Visitor Management overview](./index.md)
- [Check-in flows](./check-in-flows.md) — kiosk paths for invited guests
- [Notifications](./notifications.md) — area channels vs host arrival email
- [Badges and wallet passes](./badges-and-wallet.md) — QR, wallet, and printed badges