An ESD testing system can be assessed for integration with access control, attendance, HR and card-management platforms, but compatibility cannot be promised before the real interfaces are reviewed. The project must identify the owner of personnel master data, the mapping between employee IDs and card numbers, the system responsible for ESD test modes and area permissions, and whether test or passage events must be returned. These platforms serve different purposes, so “integrated” is not a sufficient description of the data and release responsibilities.
Separate each system’s responsibility
- HR commonly supplies employee identity, organisation and employment state; it does not automatically own ESD rules or release doors.
- A card platform may own card-to-person relationships, but live APIs and write-back vary by product and version.
- Access control manages area permissions, controllers and door events; the point at which ESD status enters its decision must be defined.
- Attendance applies shift and event-validity rules. An ESD timestamp may be exchanged, but is not automatically a valid attendance event.
Start with a stable person identifier
Employee numbers, access-control person IDs and card numbers need a governed mapping. Without it, the test and door event may be assigned to different people.
The operating process must cover hires, transfers, terminations, lost cards and reissued credentials—not only the initial import.
Typical data directions
- Existing systems to ESD: stable person ID, required organisation data, active state, credential relationships and any externally owned permission.
- Within ESD: assigned test mode, wrist and footwear results, decisions, terminal, entrance, direction, time and exceptions.
- ESD to existing systems: test completion, decision and only the approved release or event summary.
- Direction, timing, modification rights and retry behaviour remain subject to the actual interfaces and implementation scope.
Define who makes the release decision
The ESD platform may evaluate test status and area permission before issuing one release, or it may provide the test result to an existing access platform that makes the combined decision. Either design can be assessed, but two systems must not independently release the same door, and an outage must not silently bypass the other condition.
Before integration testing, freeze the identity, required-test and area-permission conditions, plus the owner of the combined decision, execution and feedback.
Recommended integration sequence
- Inventory the products, versions, interface documents and maintainers.
- Establish employee and credential mappings.
- List fields each system supplies, accepts and must not modify.
- Assign ownership of test modes, permissions and the final decision.
- Test hires, transfers, terminations, denied permission, failed tests and synchronisation errors.
- Pilot one entrance, then resolve timeout, offline and conflict handling before expansion.
Confirm before implementation
- Formal system names, versions, interface documentation and owners.
- Ownership of personnel, cards, organisation and status.
- Data direction, triggers, frequency, logs and retries.
- One accountable system for the final access decision and physical release.
- Access and retention rules for personnel, biometric and ESD data.
Frequently asked questions
Does an available API guarantee integration?
No. Required fields, permitted operations, frequency, errors and the site workflow still need to be verified in a test environment.
Can ESD results be written to attendance?
A project may exchange an event or summary, but a passed ESD test and valid attendance use different business rules.
Will an HR-synchronised terminated employee become invalid automatically?
Only if status changes are included and enforced by both ESD and access systems. Termination, transfer, rehire and failed synchronisation require tests.