Technical buying guide
Turnstile Access Control Integration Checklist
A turnstile can look straightforward on a floor plan: present a credential, unlock a passage, and record entry. The integration work begins when the project asks what happens after a credential is accepted. Does the access controller send a brief release signal or maintain an open state? How does it know that someone actually passed? What happens when two people approach together, the network fails, or the fire alarm activates?
This checklist helps an integrator turn those questions into an interface schedule before equipment is ordered. It applies across tripod, swing, flap, speed-gate and full-height designs, but the final answers must come from the selected models, controller manuals and local life-safety design. Our Turnstiles & Pedestrian Access range is the product starting point; this article covers the connection between systems.
Define the passage before choosing a reader
Draw the actual pedestrian route. Mark entry and exit directions, staffed reception, the accessible route, visitor check-in, emergency exits and nearby doors. A turnstile should not be specified as the only route for people who cannot use that passage. The width and movement of an accessible entrance, and its release during an emergency, need review under the rules that apply to the site.
State the operating mode for each direction. Staff may use a credential on entry while exit is free; another site may control both directions. Visitors may be escorted or given temporary credentials. These are operational requirements, not features that can be assumed from the word “turnstile.” In an office-building entrance, the reception process may determine whether a visitor reader belongs at the gate or at a desk upstream.
Ask the owner to identify peak arrivals and the acceptable queue area. Throughput figures from a catalogue are not a substitute for testing the combined credential, gate movement and human behavior. People carrying luggage, using mobility aids or accompanying children may require a different route or more time than a nominal passage rate suggests.
Document every signal between controller and gate
Make one row per signal, with its physical terminal or network message, direction, normal state and expected response. Do not approve an integration based only on “supports access control.”
| Interface question | Specify before purchase | Verify at commissioning |
|---|---|---|
| Release command | Direction, pulse/hold behavior, electrical or protocol interface | One valid credential enables only the intended passage |
| Passage completed | Sensor or rotation feedback available on the selected model | Event means a person passed, not merely that access was granted |
| Passage timeout | What happens if permission is granted but nobody enters | Gate returns to its agreed secure state without a false passage record |
| Alarm or obstruction | Which events are exposed to the controller/operator | Message and physical gate behavior agree |
| Power and network loss | Site-approved local behavior and power source | Observed behavior matches the safety and security design |
| Emergency release | Trigger source, responsible controller and reset procedure | Local authority-approved test is completed and recorded |
A relay contact and an IP interface are not interchangeable. The controller may have more information available through one method than another. Request a current interface document for the exact gate version, and identify who supplies the reader, credential platform, access controller, wiring and software configuration. A face-recognition terminal is one possible credential device in the site architecture; its presence on the website does not establish compatibility with every turnstile or access platform.
Separate access approval from physical passage
An access system can approve a credential even when the passage is blocked or the person walks away. If the operator’s report counts approvals as entries, occupancy and attendance records can be wrong. Agree which event starts the transaction, which event confirms passage and how abandoned attempts are logged.
Test both directions and unusual sequences: a person changes direction, someone follows closely, a visitor presents an expired credential, or a gate remains open longer than expected. The selected turnstile may provide anti-tailgating or passage-detection options, but those functions must be specified and proven on the actual configuration. Do not use a generic feature list as acceptance evidence.
The record-retention question also belongs in the design. Identify what personal data is created by readers or cameras, who can access it, how long it is kept and which local privacy rules apply. A biometric identification method warrants separate privacy and legal review before procurement.
Agree on failure and egress behavior with the right people
Security teams may prefer a locked boundary during a fault, while emergency planners require a clear route out. Those requirements cannot be resolved by a marketing phrase such as “fail safe.” Document what happens on loss of mains power, backup power, controller communication and fire-alarm input. Then have the site’s qualified fire, accessibility and safety professionals approve the design under the applicable rules.
For a full-height turnstile, swing gate or other powered barrier, ask for the model-specific emergency and manual-release instructions. The Boon Edam Turnlock 100 product data shows how such behavior is specified for one particular model; it is not evidence for a Zibor Park gate. Check whether the chosen accessible route remains usable if the turnstile is unavailable. Staff should know which fault can be reset locally and which requires an installer. Product designs differ; this article does not state that any Zibor Park model automatically meets a jurisdiction’s egress or accessibility rules.
Use a signed integration and acceptance sheet
The handover should name both the equipment supplier and the systems integrator responsible for each interface. Record the gate and controller model, firmware or configuration version, reader type, signal map, cable schedule and approved operating modes. Keep a test result for valid and invalid credentials, both passage directions, no-passage timeout, obstruction, power/network loss and the site-approved emergency response.
When asking us about a pedestrian entrance, share the floor plan, required direction of travel, credential method, expected peak use and existing controller documentation. We can discuss relevant pedestrian access equipment and identify the model-specific documents the integration team needs. Final interface and life-safety approval remains a project decision supported by the actual manuals and local professionals.