A standalone system works for about a year — then someone asks why a departed employee can still approve visitors.
A visitor management system that stands alone works for about a year. Then someone asks why host names are maintained twice, why contractor hours are keyed into a second system by hand, and why a departed employee can still approve visits.
Integration is what prevents all three. This guide covers what each connection actually gives you, what it requires from your side, and how long it takes.
| Without integration | With integration |
|---|---|
| Host list maintained manually | Hosts come from the directory |
| Leavers stay active until noticed | Departure removes access |
| Contractor hours re-keyed | Hours flow from gate events |
| Driver arrivals checked by phone | Matched against the order |
| Badges configured separately | Provisioned from the approved visit |
The second row is a security issue rather than an administrative one: an employee who left three months ago should not still be approving visitors, and without directory or HR integration nothing removes them until someone notices.
What it gives you: the host list, department structure and group membership come from a source your organisation already maintains, so a new joiner can host a visitor without anyone adding them, and a leaver stops being able to.
What it requires: a service account with read access, agreement on which attributes map to what, and a decision on sync frequency. What to decide explicitly: whether sync is one-way — which it should be, in almost all cases. A visitor system should read from the directory, not write to it.
Typical effort: days rather than weeks, assuming IT availability. See implementation timeline and steps.
What it gives you: administrators and hosts sign in with existing corporate credentials, subject to your existing authentication policy including multi-factor requirements — and lose access immediately when the account is disabled.
The distinction worth keeping clear: SSO governs who administers the system; directory sync governs who appears in it as a host. They are separate integrations solving separate problems, and implementing one does not deliver the other.
Note also that SSO applies to internal users, not to visitors — a visitor should never need an account.
What it gives you: the joiner–mover–leaver lifecycle handled automatically. A departure in HR removes hosting rights and approval authority without an IT ticket.
Where a directory is already synced with HR, this may be redundant. Where it is not, HR integration closes the gap the directory leaves: a directory account is often disabled some time after the person actually left, and the interval is exactly the exposure worth closing.
What it gives you: a delivery driver matched against an actual purchase order, and contractor hours derived from gate events flowing to whatever handles payment.
This is the integration with the clearest financial return and the most common design mistake — trying to synchronise too much. The useful scope is narrow: read order references and validity; write back gate-derived hours. Anything broader creates a maintenance burden that outlives its benefit.
The same narrow-scope principle applies to facilities systems, where a work order becomes the reason a technician is allowed through the gate. See visitor management for factories.
What it gives you: an approved visit provisions a credential with the right zones, and expiry or check-out revokes it automatically.
Four questions determine whether it works in practice:
Question three is the one to press: on most controller-based systems, a credential revoked centrally keeps working until the next sync. That window is a risk to size rather than to ignore. See visitor management vs access control.
The two work in opposite directions and most mature integrations use both: an API for pulling data on request, and webhooks for being told the moment something happens.
What to verify before relying on either: whether the API is documented publicly or on request, whether it is versioned so an upgrade will not break your work, what the rate limits are, whether webhooks are signed for verification, and what the retry behaviour is on failure.
Also confirm whether API access is included in your tier or priced separately — it is frequently the latter, and that turns every future integration into an upgrade conversation.
Often, and in two distinct ways worth separating in a quotation: the API or connector as a licensed capability, and the integration work itself as a service. A vendor may include the first and charge for the second, or the reverse.
The question that clarifies it: is this integration a product feature or a project? A product feature is configured, documented and maintained through upgrades. A project is built once, and someone pays to fix it when either system changes.
| Integration | Typical effort | Main dependency |
|---|---|---|
| Directory sync | Days | IT availability, attribute mapping |
| SSO | Days | Identity provider configuration |
| HR sync | Days to weeks | HR system's interface |
| Access control | Weeks | Incumbent vendor's cooperation |
| ERP or facilities | Weeks | Scope discipline |
| Webhooks | Days | Your receiving endpoint |
The fourth row is consistently the longest, and the reason is rarely technical: it depends on a third party with no stake in your project. Engage that vendor before the schedule is fixed, not after.
Haseen provides directory and SSO integration, a documented read API, and signed webhooks with retry and a delivery log — so events reach your systems as they happen and details are fetched under your own permissions. Integration scope is agreed as configuration or project explicitly, rather than discovered later.
See Haseen integrations.
Five categories cover most requirements: identity directories for host records and permissions, single sign-on for administrator access, HR systems for the joiner–mover–leaver lifecycle, ERP or facilities systems for purchase orders and work orders, and access control for physical enforcement. An API and webhooks cover anything outside those.
Once configured, yes — hosts, departments and group membership come from the directory on a defined schedule. It needs a service account with read access, agreed attribute mapping and a sync frequency. Keep it one-way: a visitor system should read from the directory, never write to it. Typical effort is days, gated mainly by IT availability.
Verify five things before relying on one: whether documentation is public or on request, whether it is versioned so upgrades will not break your integration, what rate limits apply, whether webhooks are signed for source verification, and what retry behaviour applies on failure. Also confirm whether API access is in your pricing tier or charged separately.
Frequently, and in two ways that a quotation should separate: the connector or API as a licensed capability, and the integration work as a service. The clarifying question is whether a given integration is a product feature or a project — a feature is configured, documented and maintained through upgrades; a project is built once and needs paid repair when either system changes.
Directory sync, SSO and webhooks are typically days; HR sync days to weeks; access control and ERP typically weeks. Access control is consistently the longest, and for a non-technical reason: it depends on the incumbent vendor, who has no stake in your project. Engage them before fixing the schedule rather than after.
Directory sync, in almost every case. It is quick, it removes the most manual maintenance, and it closes a genuine security gap — departed employees who can still approve visitors. Access control usually delivers more operational value but takes longer and depends on a third party, so start it early in parallel rather than first in sequence.
Check whether anyone who left your organisation in the last six months can still approve a visitor. That single answer usually settles which integration to do first.
Directory and SSO integration, a documented read API, and signed webhooks with retry and a delivery log.