HR, identity, and visitor integration

HR records, visits and access entitlements have separate owners and lifecycles. Define how changes move between the systems and how conflicts are resolved.

Overview#

Employment, digital identity, physical identity, access entitlement, credential, visit, and presence are related but distinct. Integration should propagate approved lifecycle facts while each system retains authority for its own decisions and evidence.

Authority map#

Create a field level matrix for source, owner, purpose, validation, target, transform, conflict, maximum age, retention, and deletion. A “master system” label is too coarse.

Durable identity and matching#

Use a non reassigned, durable source identifier plus authoritative provenance. Email, name, phone, employee number, credential number, and department can change or collide. Automatic matching on weak attributes can merge two people and create unauthorised access.

Represent person, employment/engagement, digital account, physical holder, role, entitlement, credential, visit, sponsor/host, and vehicle as separate entities with explicit relationships and validity intervals. Record confidence and review for any non authoritative match.

Lifecycle#

source change -> validated identity event -> policy/approval evaluation
 -> target provisioning request -> target result
 -> entitlement/credential state verification -> exception/reconciliation

Handle pre hire/scheduled activation, join, internal move, additional role, temporary assignment, leave/suspension, return, termination, extension, rehire, contractor end, and corrected records. Define effective time and timezone, approval, dependency ordering, retry, duplicate, out of order, and rollback semantics.

For high risk cessation, distinguish request generated, target accepted, holder disabled, controller updates distributed, offline controller exposure, mobile credential revoked, and physical credential recovered. Report unresolved targets; never close the workflow because one API call returned success.

Provisioning interfaces#

RFC 7643 defines the SCIM core schema and RFC 7644 defines its HTTP based protocol. SCIM does not define an organization's entitlement policy, physical credential security, controller distribution, or door semantics. Verify schema extensions, PATCH/replace/delete behaviour, filtering, pagination, ETags/versioning, bulk operations, errors, and product specific limits.

PSIA describes PLAI as an interoperability approach for normalising and sharing identities and access privileges across physical access control systems. Use its published specifications and product evidence for exact interoperability; don't infer conformance from generic API support.

Visitor and temporary identity#

Capture only necessary visitor, host, approval, purpose, validity, location, escort, training/terms, credential, vehicle, and visit outcome data. Enforce expiry in the authoritative access system, including controller/offline behaviour. Separate preregistration, identity verification, arrival, credential issue, access activation, check in/out, credential return, cancellation, no show, and deletion.

Self service kiosks, document capture, watchlist checks, biometrics, host notification, and cross site reuse need separate necessity, security, privacy, accessibility, and error review. Avoid making a visitor's access or safety depend solely on personal email/SMS or a mobile application.

See Visitor, identity, and elevator integration.

Security, privacy, and reconciliation#

• Use separate, least privilege read and write workloads; scope by tenant/site/object/attribute.
• Protect API tokens/keys and personal data; restrict bulk read/export and support access.
• Validate allowed attribute changes and prevent source data from assigning privileged roles directly.
• Retain raw source event/reference, transform/version, request/result, approver, and exception.
• Reconcile authoritative source, target database, controller distribution, and credential state on a controlled schedule.
• Detect orphan accounts, duplicate holders, expired visits, stale roles, future dated anomalies, and failed revocations.
• Define lawful purpose, transparency, correction, minimisation, retention, deletion, and cross border/provider boundaries.

Acceptance evidence#

Use synthetic or expressly authorised test identities in an approved isolated process to cover the lifecycle matrix, duplicates, delayed/out of order changes, retry, partial target failure, source correction, termination, rehire, offline controller, privacy deletion, and recovery. Record source, integration, and downstream reconciliation evidence separately.

Return to Integration platforms.