Appearance
Visitor Management
The front desk for a building: who is coming, who is here, who said they could be, and the badge that lets the rest of the platform see them.
Where it stands
Built: host companies, reception (register, approve — in the app or from Telegram — check in with a badge, check out), the blacklist, notifications, webhooks, the expiry sweep, host pre-registration by email, the visitor's own registration in the visitor app, badge auto-checkout by presence, the Security Watch whitelist, OAIA, reports, DSAR, the importer from the legacy VMS (run on site by Synchroweb), and the access-control gate connector. Checked function by function against the legacy VMS: everything a customer used has a home here, and the few things that were dropped are listed in the parity record with the reason. Complete.
Who it is for
| Reception and guards | The desk: expected today, on site now, check in, check out, register a walk-in |
| Each host company's approvers | The approvals queue for their company — and only theirs |
| Hosts | Told when their visitor arrives |
| A company's own admin | Its members, form, terms and auto-approval, from inside the app |
| Whoever runs the building | Companies, zones, members and the visit settings under Your Apps → Visitor |
Host companies
A building is usually several occupiers — one per floor, one per unit — and a visitor is visiting one of them. The app calls these host companies. Each has its own zones, its own approvers and hosts, its own registration form and terms, and its own auto-approval switch. A visit names the companies it is for, and each company approves separately: a visit to two units needs both to say yes, and neither sees the other's answer.
A building with a single occupier still has one company — it is what a visitor is approved for.
Who signs in where. Everyone who acts on visits is an app user of the building with the Visitor app granted — the same login as every other mini app. What they see is their company membership and its role:
| Role | Does |
|---|---|
| company_admin | Manages the company from inside the app: members, form, terms, auto-approval, domains |
| approver | Approves and denies the company's visits |
| host | Is told when a visitor for the company arrives |
| reception | Serves the desk for that company |
One person may belong to several companies — a guard can serve three lobbies, a managing agent can approve for every unit. A user whose grant is scoped to assigned records sees only the companies they belong to; opening another company's visit by its address gets a 403, not a page. A user with all — the building's own reception — sees every company. The grant's configure permission is the building admin and may do everything.
A visit
A visit is one or more people (a group shares one badge), for one or more companies, from a start time to an end time, with a status:
| Status | Means |
|---|---|
| Awaiting approval | At least one company has not decided |
| Approved | Every company said yes; the visitor may check in |
| Denied | A company said no — the visit is over |
| On site | Checked in |
| Checked out | Left after the end time, or was checked out as expired |
| Expired | The end time passed and nobody arrived |
| Cancelled | Revoked by reception |
Every visit — open or closed — is on the Visits screen, filtered by status, host company, how it was registered, and date. A visit that is still open can be rescheduled from its page.
A company that withdraws its approval while the visitor is on site ends the visit there and then — checked out and cancelled with the reason — rather than leaving a denied row under an on-site visitor.
Leaving before the end time goes back to approved, not checked out: a visitor who steps out for lunch is checked back in against the same approval, and each entry is its own stay in the history.
A walk-in with no end time ends after the building's default (twelve hours unless changed). A visitor still on site past the end time plus the grace period is checked out as expired by the sweep, and their badge freed.
Five ways a visit begins
| Who | Where | |
|---|---|---|
| Reception | The desk, for a walk-in or a visit for later | The app's Register screen. Several people can go on one group visit sharing a badge, or — tick register each person as a separate visit — become one visit each, so each gets their own approval, badge and status. A photo can be taken at the desk |
| Pre-registration | A host expecting someone | /{organisation}/visit/register — a work email, a six-digit code, then the people expected. A company whose domains match the host's email treats that as the host vouching and approves on the spot; a company with no domains accepts anyone and follows its own auto-approval switch |
| The registration page | Anyone, on any phone — or a tablet at reception | /{organisation}/visit: a plain page, no app, no floor plan, no account. Two flows, chosen on the settings page. One page: who they are, who they are visiting, the companies' questions, the terms, an optional photo, all together. ID first: the ID number on its own screen (a blacklisted ID is stopped right there, and a returning visitor's details come back), then the terms on their own screen, then the details with the ID already filled in — the shape a lobby tablet and an identity provider want. Either way the visitor ends on their status page with the QR, which updates on its own as the hosts decide. Add ?kiosk=1 on a reception tablet and the screen clears itself after each visitor. The link and its QR are on the settings page |
| The visitor app | Anyone who scanned the venue QR, in a building with a floor plan | Register your visit in the visitor app: who they are, which companies, each company's own questions (the required ones are enforced), the terms, and an optional selfie for the desk. The card on the app's home page then shows the visit's status, and the QR appears the moment a host approves. One open visit per person: registering again hands back the one they have |
| A meeting | A host booking a room | An external attendee on a Meeting Room booking becomes an expected guest: a visit for the meeting's time (half an hour either side), hosted by the person who booked, approved because a host vouches for their own guest, and an email with the QR. The guest's ID is not known yet — the desk takes it on arrival, and a blacklisted ID given then ends the visit. Cancelling the meeting cancels the visits. A switch on the settings page |
| Import | The legacy VMS | Synchroweb runs the importer on site: companies, visitors, visits, stays, blacklist, forms and terms come across, with each visitor's ID re-hashed under your organisation's own key |
The pre-registration code goes out through the organisation's SMTP connector; with none, the portal says so rather than pretending. The host who pre-registers gets a confirmation listing each visit with its own status link — a page the visitor can open from the approval email too, showing the status and the QR to present at the desk, and nothing about anyone else. The link and its QR are on the settings page, ready to print for the lobby.
Identity and the blacklist
A visitor is identified by their IC or passport number. The number is never stored. It is hashed with a key that belongs to your organisation, so a returning visitor is recognised and a blacklist entry matches, and what a receptionist sees is a masked copy (9001******55). The legacy VMS used one hard-coded key for every customer; this does not.
The blacklist blocks an ID from registering at all — for the whole building (the building admin's call) or for one company (its own admin's). A blocked registration is refused before any row is written, and the company's approvers are told someone tried.
Verified IDs. The ID verification setting names an identity provider for the ID-first flow. MyDigital ID is listed as a placeholder: its button appears on the ID step but does nothing until the provider is connected to your organisation. When it is, a visitor who signs in with it arrives at the details step with their full name and ID number filled in and locked, and the visitor record carries verified by MyDigital ID — the desk sees the difference between a typed number and a verified one.
A visitor's record — name, phone, email, company, photo — can be edited from their page, and visitors can be imported from a CSV (name, ID, ID type, phone, email, company) for a customer moving lists across; the ID is hashed on the way in like any other.
The badge
Checking a visitor in can assign a badge — any free platform tag, scanned or typed by MAC, name or uid. The tag is bound to the visitor's own person entity for the stay and released at check-out — by reception, by the sweep, or, if you set check out a badge no gateway has heard for N minutes, on its own when the badge falls silent. Set that longer than the gaps in your gateway coverage, or a visitor in a dead spot is checked out while still inside. That one binding is what puts the visitor on the floor plan, in Roll Call by name, in the trail reports and in Security Watch — nothing extra to set up. Security Watch is told more than that: a stay whitelists the visitor in the host companies' zones until check-out, so an approved visitor after hours is not an after-hours incident, while a restricted zone stays restricted. A visitor's entity is created on their first check-in and labelled visitor. The visitor can do the check-in themselves: reception hands over the badge, the visitor types the code printed on it into the visitor app, and the same rules apply as at the desk — approved visit, free tag, badge required if you say so. From then on the app offers directions to the host company on the map, and a check out when they leave. A switch on the settings page turns self check-in off for buildings where the desk does it all. A badge can be made compulsory in the settings; an access-card number can be recorded alongside for the gate connector to use — and a badge that is also an access card remembers its number, so it is typed once and reused on every later check-in. A badge can be swapped mid-stay from the visit page; the desk also finds an on-site visit by scanning or typing the badge's MAC. While a visitor is on site, their page and the reception board show where the badge was last heard and when.
The gate
Where the building has an access-control system, the visitor's access card is granted at check-in and revoked at check-out without anyone at the desk touching the gate software. Set the system up once under Integrate → Connectors → Access Control (Gate) — its server, the API logins (several, tried in turn, because the system allows one session per login), the door controllers to push to, and the door-access right that means visitor. The Test button logs in and asks each controller whether it is up.
From then on a check-in that records a card number names the card holder after the visitor, gives the card the visitor right and pushes it to the controllers; a check-out takes the right away. Either outcome — including a failure — is written into the visit's history, and a gate that is down never blocks the desk: the visit is checked in, the history says the gate was not updated.
With check out visitors when the gate records their exit on, the gate is asked every five minutes about every visitor on site with a card, and an exit swipe after their check-in checks them out — the third way a stay can end, after reception and a silent badge.
One system speaks this protocol today: MicroEngine xPortalNet.
Notifications and integrations
- Registration → each pending company's approvers, by push and email, plus the company's PIC address.
- Approved / denied → the visitor by email if they gave one, and the named host by push.
- Arrived → the named host, or the company's hosts if none was named.
- Blocked → the approvers of the companies asked for.
Email goes through the organisation's SMTP connector; with none, push still goes out.
Telegram approvals use the organisation's Telegram connector (Integrate → Telegram). Give a company the id of its own group or person — add the bot to the group and send /id to see it — press Connect Telegram once on the settings page, and every registration for that company arrives in the chat with Approve and Deny buttons. A press decides the visit; Deny asks the chat to reply with a reason (or /skip). Only the company's own chat can decide for it, and the message is rewritten once the visit is decided, from Telegram or from the app. Webhooks carry every transition — visitor.registered, visitor.approved, visitor.denied, visitor.checked_in, visitor.checked_out, visitor.cancelled — see the webhook events reference.
On the wall
The TV Dashboard has a Visitors widget: on site now, expected today, awaiting approval, and how many arrived today. Counts only — the board is public.
Integrations: what a scan in or out sends where
The Integrations card on the settings page is where a building decides what happens on check-in and check-out beyond the badge itself:
- Access control (gate). Two switches — on check-in, grant the card and on check-out, revoke the card — and the access-right id sent with each, which defaults to the connector's own (
0009/0000for MicroEngine) and can be overridden here without touching the connector. A badge swap revokes the old card and grants the new one under the same switches. The connector itself lives under Integrate → Access Control. - Notifications. A grid of event × channel: registered (approvers and the PIC; push, email, Telegram), approved / denied (visitor and host; push, email), arrived (host; push, email), blocked ID tried (approvers; push). Untick what you do not want. Email still needs an SMTP connector and Telegram the connector plus a chat id on the company.
- Webhooks. Every transition is an outbound webhook event; subscribe under Integrate → Outbound webhooks.
- Rules. With Visits trigger rules on, every transition is also a rule trigger: a real-time rule with the condition Visitor event =
checked_in(orregistered,approved,denied,checked_out,cancelled,badge_changed) runs its actions — HTTP post, MQTT, Home Assistant, a message, a work order — with,,,,,andavailable in the templates. Scope the rule to a zone, venue or location and it fires only for visits to companies with zones there; scope it to a device and it fires for that badge. This is how a building wires a scan-in to a door controller the platform has no connector for, or turns the meeting-room lights on when the guest arrives.
Reports, OAIA and erasure
Reports, in the app, over any period: visits and arrivals by day, by host company with approval time, by type and channel, how stays ended (reception, badge went quiet, time ran out), arrivals by hour of day, average stay by visit type, approval time per approver, returning visitors by how long since their last visit, the most frequent visitors, and a CSV of every visit. A company admin sees their company's numbers. Where a visitor went inside the building is not a visitor report: it is the entity trail, in the platform's own reports, because the badge made them an entity.
OAIA reads the same tables: it can say who is on site, how long approvals take and which company's visitors leave without checking out, and it raises a finding for a visitor still on site half an hour past their end time or one kept waiting at reception for approval.
Erasure. A visitor found by name, phone or email under Privacy (DSAR) can be exported and erased: name and contact replaced, the ID hash discarded so a return is a new person, form answers and badge numbers cleared, the person entity and its trail erased with them. The visits themselves keep their statuses — the building's record of who was approved and when survives, the person does not.
Setting it up
Your Apps → Visitor, on the admin side:
- Add the host companies. Name, PIC email, auto-approval, the zones its visitors may enter, and its registration form and terms.
- Add members. Every approver, host and receptionist must first exist as an app user with the Visitor app granted; then add them to the company with a role. Give the building's own reception the all data scope and no company; give a unit's staff the assigned scope and their company.
- Visit settings — the table below. Each has a default; decide them rather than inherit them.
A company admin then finds My company in the app and takes it from there.
The settings
| Setting | Default | What it does | Worth knowing |
|---|---|---|---|
| Walk-in default length | 12 hours | A walk-in registered with no end time ends this long after it starts | Match it to the building's day; the legacy VMS closed walk-ins at midnight |
| Auto-checkout grace | 2 hours | A visitor still on site this long past the end time is checked out as expired and the badge freed | Usually fine as is |
| Check out a badge no gateway has heard for N minutes | 0 (off) | The badge going quiet is treated as the visitor having left | Only where gateway coverage is continuous — a dead spot checks a visitor out while they are still inside |
| A badge is required to check in | off | The desk cannot check anyone in without assigning a tag | Buildings that had tags under the old VMS usually say yes |
| Show terms and require acceptance | on | Terms are shown and must be accepted — the building's and the companies' — on the registration page, the host portal and the visitor app | Off means no terms anywhere, including the companies' own |
| Registration page flow | one page | One page, or ID first (ID → terms → details) | ID first for a lobby tablet or an identity provider |
| ID verification | typed | Which identity provider the ID-first flow offers | MyDigital ID is a placeholder until connected |
| Visitors may register on the public registration page | on | The /{organisation}/visit page is open | Off for a building where only reception, hosts or the app may register |
| Visitors may check in and out from the visitor app | on | Reception hands over the badge; the visitor types its code in the app, and checks out the same way | Off if the desk must see every arrival |
| Meeting Room guests become visits | on | An external attendee on a room booking is pre-registered for the meeting's time | Only with the Meeting Room app; the person booking must be a member of a host company, or the building must have one company, or nothing is created |
| Telegram approvals | not connected | Registrations go to each company's Telegram chat with Approve / Deny | Needs the organisation's Telegram connector under Integrate; put the group's chat id on the company, then Connect Telegram once |
| Access control (gate) | no connector | A visitor's card is granted at check-in and revoked at check-out | Create the connector under Integrate → Access Control and use its Test button before the first check-in. Card numbers are typed once and remembered per badge |
| Pre-registration link | on this page | The link and QR hosts use to register the people they expect | Print it for the lobby; anyone from a company's allowed domains gets through |
| Integrations — gate on check-in / check-out and the right ids, the notification grid, visits trigger rules | gate on, all channels on, rules on | What a scan sends where and who is told | Turn off channels you do not use; the rule trigger is the general-purpose hook |
| Visitor registration page link | on this page | The link and QR a visitor opens to register themselves | The door QR for a building without floor plans; ?kiosk=1 for a tablet |
Coming from the legacy VMS: your VMS users become app users with a company membership (company admin, approver, host or reception); your guards become app users with the all data scope and no company. Accounts are invited by your admin — the import brings visitors, visits and settings, not logins.
When it disappoints
The register screen shows no companies. None are set up, or the user's scope excludes them all.
Approvals says "not an approver". The user's membership role is host or reception; only approver and company_admin decide.
Check-in refuses the badge. The tag is bound to something already — a staff entity, an asset, or another visitor still on site. Free it, or use another.
The visitor never appears on the floor plan. No badge was assigned at check-in, or the tag is not reporting.
Nobody was emailed. No SMTP connector is enabled under Integrate; push notifications still went to the approvers who have the app open.
Nothing arrives in Telegram. The company has no chat id, the bot is not in that group, no Telegram connector is enabled, or Connect Telegram was never pressed after the connector was added.