Visitor, identity, and elevator integration
Visitor, HR, access control and lift systems own different records and decisions. Define the approved exchange and permissions between them.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Integration model only; no lift safety/control sequence, destination dispatch command, access policy, identity proofing level, or local visitor/legal requirement.
On this page
Overview#
HR, identity governance, visitor management, PACS, and lift systems each own different facts. Integration should propagate the minimum approved intent, not make any one source omnipotent.
Authority map#
| System | Authoritative for | Must not imply automatically |
|---|---|---|
| HR/workforce | Employment/contract relationship attributes | Door/floor authorisation |
| Identity governance | Account lifecycle, group/approval workflow | Physical presence or passage |
| Visitor management | Visit, sponsor, expected time, check in status | Unsupervised access rights |
| PACS | Physical credentials, access rules, decisions, door audit | Employee/visitor master identity |
| Lift destination/control | Approved car/floor operation and safety logic | Identity lifecycle or building occupancy truth |
Provisioning pipeline#
source change -> validate/map -> approval/policy -> PACS identity/credential/rules
-> controller download/ack -> effective state reconciliation -> expiry/revocation
Use immutable source IDs and mapping versions; don't join people by display name/email alone. Effective start/end times, timezone, sponsor, site, role, credential status, and policy reason need explicit semantics. A successful API response isn't proof all controllers are current.
RFC 7643 and RFC 7644 define SCIM user/group schema and HTTP provisioning protocol for cross domain identity management. SCIM does not define PACS doors/access rules or complete authentication policy. PSIA's PLAI overview specifically addresses dynamic physical/logical identity and privilege transfer to disparate PACS, based on its own specification scope.
Visitor lifecycle#
Require sponsor and purpose; verify the visitor under local policy; scope site/areas/schedule/escort; issue a visibly temporary, unique credential; activate at check in rather than invitation where appropriate; expire/revoke automatically; record return/loss; and handle no show/cancel/overstay. Don't expose host calendars, attendee lists, ID documents, photos, health/vehicle details, or movement beyond need.
Pre registration links and QR credentials must be signed/scoped/fresh, protected against forwarding/reuse, and revocable. Reception overrides require reason and audit.
Lift/elevator boundary#
PACS may provide an approved floor set or destination request; the certified lift system retains motion, door, load, emergency, fire service, and safety authority. Use the exact manufacturer approved interface and local lift/fire standards. Never write controller registers or simulate safety inputs from a generic integration.
Distinguish credential permitted floors, submitted destination, accepted destination, assigned car, passenger entry, car movement, and arrival. A destination acknowledgement isn't passage or safe transport.
Failure and privacy#
Define IdP/HR/visitor/PACS/lift/network/time outage, duplicate identity, delayed termination, expired visit, controller offline, visitor credential loss, destination rejection, emergency mode, and recovery. Emergency/accessible egress/operation must not depend on enterprise provisioning availability.
Reconcile active people/credentials/visits regularly; alert orphaned accounts, overlong validity, failed revocation, duplicate source links, and controller divergence. Keep movement/access histories purpose limited and restricted.
Return to Access control systems.