Skip to content

Visitors

The Visitors module replaces the gate logbook. Pre-register guests, scan them in with QR codes, and keep a searchable record of every arrival.

What residents see

Residents have a My Visitors view:

  • Invite a visitor — enter the visitor's name, expected arrival date/time, and optional vehicle plate. The system creates a pre-registered pass with a QR code that the resident can email or text to the visitor.
  • Invite companions — add additional visitors arriving as a group with the lead. Companions are linked to the lead and surfaced together in the Expected Today + Visitor Log + My Visits views as a "👥 +N" badge that expands to show each companion. Each can still check in / out independently.
  • Today — anyone they've pre-registered who's expected today, plus who has already arrived (and at what time).
  • Cancel a pre-registered visitor — if the visit falls through, open the row → Cancel before they arrive. Removes the QR from the gate's expected-arrivals list. Cannot be undone once cancelled (re-invite if needed).
  • History — past visitors with check-in/out times.
  • Visitor cap status — if the facility has set occupancy limits per unit type, residents see how many more visitors they can host today.

What guards see

Guards have a focused Visitor Check-in screen:

  1. Scan QR — the visitor shows the QR they received. The screen confirms the host unit, the resident's name, and any vehicle linked to the pass.
  2. Type a name — for walk-up visitors who weren't pre-registered. Guard picks the unit they're visiting; the resident is notified (push + email) and can approve or decline.
  3. Print pass — for facilities that issue physical badges. The printer prints a label with the visitor's name, host unit, and time of arrival.

Guards also see the day's expected arrivals at a glance — useful for planning around large gatherings (weddings, parties, conferences).

What facility admins do

Configure visitor caps

Go to Settings → Visitor occupancy caps per unit type:

  • Override the platform-default occupancy cap for each unit type (Studio: 2 visitors, 1 Bedroom: 4, etc.).
  • Leave a value blank to use the platform default.
  • Set unit type to "Commercial" on the unit itself to disable cap enforcement entirely (useful for offices in mixed-use buildings).

The cap counts residents + visitors + short-stay guests at any one time. When the cap is hit, the gate refuses additional visitors until someone checks out.

Review the gate log

The Activity tab shows every check-in and check-out, filterable by: - Date range - Unit - Visitor name - Guard who logged it - Vehicle plate

Useful for: - Investigating incidents ("who was here at 3 AM on the 14th?") - Resolving disputes ("did anyone visit unit 4B yesterday?") - Auditing high-traffic days

Pre-register a vendor crew

For scheduled deliveries, contractors, or service crews:

  1. Visitors → Pre-register tab.
  2. Enter the lead person's name, expected date range, and the units they'll be servicing.
  3. Generate one QR per crew member or one master QR for the lead.

When they arrive, the guard scans, the crew is in.

Permits vs visitors

  • Permits (in the Parking module) are for vehicles — long-lived, tied to a specific car.
  • Visitors (this module) are for people — short-lived, tied to a specific arrival event.
  • A visitor pass can include a vehicle plate so the guard sees both at once (single scan, both checks pass).

Tips

  • Email and Telegram are the easiest delivery channels for visitor QRs. Set them up in Settings → Notification Channels and the corresponding Send buttons appear next to every pass.
  • Cap exceedances show up as a red banner on the resident's dashboard with the option to "Request override". Management can approve overrides per visit.
  • Recurring guests (a parent who visits every weekend) can be saved as a contact so the resident doesn't have to type the name each time.
  • Walk-up workflow needs a network connection so the resident can be pinged in real time. If the gate is offline, walk-ups have to wait for manual approval — the guard can still let them in and log the entry, it just doesn't auto-notify.

Process flows

End-to-end procedures the gate / mgmt team runs day-to-day. Steps are anchored to the actual UI labels.

Walk-in visitor at the gate

Guard receives a visitor with no advance notice.

  1. Open the Visitors module → Log Visitor (or press the green + button on the Guard tab).
  2. Tap Walk-in as the entry mode.
  3. Capture name, phone, and the unit they're visiting (autocomplete suggests valid unit codes).
  4. Tap Notify resident — the host gets a push / SMS prompt to approve or deny. The visitor stays at the gate until approval or the 5-minute timeout.
  5. On approval, scan ID (camera capture) and tap Allow Entry. Print or share QR if vehicle is involved.
  6. On denial, tap Deny and select a reason — the visitor's phone number is added to a 30-day soft block for that unit.

Pre-registered visitor

Resident knows in advance someone is coming.

  1. Resident opens Visitors → Pre-register on their phone, fills name + ETA + duration.
  2. The system generates a one-time QR code valid for the chosen window. Resident shares the QR via the share-sheet.
  3. Visitor arrives, presents QR (printed, on screen, or read aloud as a 6-digit code if no smartphone).
  4. Guard scans / types the code on the Visitors tab → Scan QR — entry is logged with no extra approval needed.
  5. The pre-registration auto-closes when the visitor exits OR when the duration expires.

Recurring visitor (cleaner / nanny / driver)

Same person visits weekly on a known schedule.

  1. Resident opens Visitors → Recurring → + Add.
  2. Captures name + phone + cadence (e.g. "every Tuesday 08:00–14:00") + auto-expiry date (3 / 6 / 12 months).
  3. The platform issues a long-lived QR / 6-digit code that reactivates each scheduled window only.
  4. The recurring entry auto-expires at the chosen end-date — security in depth, so a contract that ended in March can't still produce arrivals in May.
  5. Resident can revoke at any time from the same screen. Revocation is immediate.

Resident cancels a pre-registered visitor

The visit fell through and the resident wants to remove the pending arrival before the visitor turns up.

  1. Resident opens My Visitors → row with the pre-registration.
  2. Tap Cancel → confirms intent (the cancel is final).
  3. The pre-registration row flips to Cancelled; the QR no longer matches at the gate scanner (returns Pass cancelled on scan).
  4. The gate's expected-arrivals list refreshes automatically — the cancelled visitor disappears from the day view.
  5. Cannot be undone. To re-invite, create a fresh pre-registration.

Pre-register a group (lead + companions)

Resident is hosting multiple visitors arriving together — family weekend, board lunch, contractor crew.

  1. Resident opens Visitors → Pre-register, fills the lead visitor's name + ETA.
  2. Click + Add companion to add each additional visitor's name + optional phone. Repeat as needed.
  3. The system generates one QR per visitor (lead + each companion); the lead's QR also displays "+N companions" on scan for the guard's situational awareness.
  4. On the Expected Today + Visitor Log + My Visits views, the lead surfaces with a "👥 +N" badge that expands to show each linked companion.
  5. Each visitor still checks in / out independently — the group link is purely for visibility, not a single-action group check-in.

Agent pre-registers a visitor on behalf of an owner

Real-estate agents (internal or external) holding a primary or delegated assignment on a unit can pre-register visitors against that unit through their agent portal.

  1. Agent opens their Visitors tab → + New pre-registration.
  2. Unit picker is scoped to the agent's accessible units (primary assignments + active delegations).
  3. Fill in the visitor + arrival window the same way the resident does. Companions supported the same way.
  4. Submit. The pre-registration row carries preRegisteredBy = <agent userId> so the host and the agent can both see it in their respective views.

Settings — visitor occupancy caps

Settings → Visitors → Occupancy caps:

  • Per-unit-type override of the platform-default cap.
  • Leave blank to use the default; set to 0 to refuse all visitors for that unit type (rare — typically used for sensitive units).
  • The cap counts residents + visitors + short-stay guests at any one time. When the cap is hit, the gate refuses additional visitors until someone checks out; residents see a red banner with a Request override affordance that mgmt can approve per visit.