Deployment Overview
VisitorPass is delivered as a service. Partisia operates it, and your organisation is added to it as a tenant with its own data, its own settings and its own administrators. There is nothing to install.
What onboarding needs from you is a short list of connections and decisions. This page is written to be read in advance, so that nothing on it is discovered late.
Your Organisation
We need to know, at minimum:
- The domains your organisation sends mail from. These identify your people and authorise invitations that arrive by calendar. A domain we do not recognise is treated as untrusted.
- Who your administrators are. Administrators manage employees, visit templates, documents, check-in devices and API keys. Everyone else signs in as a host and sees the visits they host.
Employees are created automatically the first time someone signs in, and when someone appears as the organiser of an ingested calendar invitation. There is no bulk import to prepare.
Your Identity Provider
There are two ways staff sign in, and nothing stops you starting with the simpler one.
Accounts held by Partisia — nothing to prepare. Tell us who needs access and we create the accounts. This is the fastest way to get people into the system and the sensible choice while you are still evaluating.
Your own identity provider — the production arrangement. Your directory stays the single place a person is created and removed, so someone who leaves your organisation loses VisitorPass access at the same moment they lose everything else. To set this up you need to:
- Register VisitorPass as an application in your provider and share the client credentials and the discovery endpoint. OpenID Connect and OAuth 2.0, SAML 2.0, and LDAP or Active Directory are all supported.
- Release the user's email address as a claim. VisitorPass matches people by email, so it is the one claim it cannot work without. A display name is used if present.
You can move from the first to the second later; tell us when you want to, so accounts line up by email address.
Calendar Invitations
Only needed if you want visits to arrive from your calendars. If visits will be created from the dashboard or through the invitation API, skip this section.
The mailbox is ours, not yours. Partisia gives your organisation an address of the form
visitorpass+your_organization_name@partisia.com and monitors it. There is no mailbox for you to
provide, no IMAP credentials to hand over, and no dependency on which mail platform you run.
What you supply instead:
- Your sending domains. The domain a calendar invitation comes from is what identifies the organisation the visit belongs to, so we need to know which domains are yours. Mail from a domain we do not recognise is recorded for review rather than acted on.
- SPF and DKIM passing on your outbound mail. VisitorPass requires both before accepting an invitation, since the sending domain is what authorises the visit.
- A habit of copying the address. Hosts add it to invitations that include external guests, exactly as they would any other attendee.
One thing worth knowing: forwarding invitations to that address from somewhere else is not a reliable substitute for copying it directly — forwarding commonly breaks SPF, and an invitation that fails the checks is set aside for review rather than acted on.
Where Guests Check In
Each entrance where guests arrive needs a device with a browser and network access — a tablet or a small screen is typical. An administrator adds the device in the dashboard, which produces an enrollment link and code; opening that link on the device completes the pairing. Nothing is installed on the device, and an unenrolled device cannot check anyone in.
A staffed reception is not required. Guests check themselves in from their own phones, so an unstaffed entrance works the same as a manned desk. What changes is the wording on screen: a per-organisation guest help instruction appears on every kiosk screen, so a site with nobody at the front can tell arrivals what to do — call the host, use the intercom — instead of sending them to a desk that is not there.
A printer is optional. Where you want guests to wear a badge, connect a printer to the check-in device — any printer the device can already print to. A single setting decides whether one is printed, and it applies to the whole organisation: labels for every guest at check-in, or none. The label carries the guest's name, who they are visiting, and the time.
Guests use their own phones, so nothing needs to be provided for them.
Verified Guest Identity
If guests must prove who they are before a credential is issued, tell us which scheme applies and for which kinds of visit. It is set on the visitor template, so it can be required for contractors and not for meeting guests.
Access Control
If VisitorPass is to supply credentials to your access control system, you need:
- Somewhere to run the integration component. Typically the machine that already runs your access control server, or one beside it — rarely new infrastructure.
- Permission to create and remove people in your access control system. Visits are created in VisitorPass, and the integration provisions the guest into your system ahead of the visit and withdraws them afterwards.
- Permission to record the outcome on the access control side, where you want that kept. Whether these permissions mean an account, a service user or a key depends on the product.
- An inbound network path from the service to that machine, so credential and door events can be delivered.
The last of these is the item most likely to need firewall work, because it is the only connection opened towards your network. Everything else is outbound.
The integration component authenticates to VisitorPass with an API key, issued in the dashboard when you set the integration up.
The specifics — which port, which credential, which fields — depend on the access control product and are covered separately for each supported system.
Connections
| From | To | Purpose |
|---|---|---|
| Staff browsers | The service | Managing and viewing visits |
| Check-in devices | The service | Check-in and check-out |
| Guest phones | The service | Adding and presenting a credential |
| Your calendar | Our monitored address | Calendar invitations, sent as mail |
| The service | Your identity provider | Brokered staff sign-in |
| Integration component | The service | Requesting credentials for guests |
| The service | Integration component | Delivering credential and door events |
Guest phones reach the service over the public internet. They never need access to your network, and they are never on it.
Before You Start
Onboarding can begin once the following are settled:
- The domains your organisation sends mail from, and who your administrators will be.
- Whether staff sign in with accounts held by Partisia or through your own identity provider, and if the latter, which one.
- Whether visits arrive from calendars, from the invitation API, or both.
- Which kinds of visit require a guest to prove their identity, and against which scheme.
- How many entrances guests arrive at, what device is at each, and whether any are unstaffed.
- Whether an access control system is in scope, and who owns it on your side.
- Whether the kiosk should print a visitor badge on check-in, and what the guest help instruction on the kiosk should say — both are set per organisation.