Elevator floor restriction works by tying a guest's credential to a destination or output configured in the access-control software, which tells the elevator controller which floor buttons to activate once that credential is presented. The access-control integrator owns the software-side configuration — the access levels, outputs, and any elevator-license module — while the elevator contractor owns the physical interface at the car controller and the protocol it speaks. Getting this right before opening means settling who licenses what, how rights change as a reservation moves through its lifecycle, and how the system behaves during a network outage.
How does a keycard actually unlock one elevator floor and not another?
In Salto's Space platform, this is handled through an "output," which is described as "a type of electrical permission or authorization used to activate devices like ESDs or elevators," and more specifically: "If you enable Floor 1 and Floor 3 in their access permissions, the user can only access those specific floors and not Floor 2" (Outputs in Salto Space). A controller connected to a relay extension board lets one or several relays — one per floor — be assigned only to users whose access permissions include that floor.
Salto's documentation also notes that this older outputs-based approach has been largely superseded: "The outputs feature has historically been used in Space to manage elevator access. However, depending on your use case, it's more common nowadays to use the optional Elevators license add-on to manage elevator access" (Outputs in Salto Space). For a new installation, ask your access-control integrator whether the project is being designed around the current Elevators license module rather than the older relay-output method, since the license-based approach is the platform's present direction for this function.
Salto's glossary describes the broader concept as a "destination": a secured access point "where presenting a key activates only the buttons for floors the user has access to," and notes that destinations "can integrate with various systems, including third-party elevator controls" (Glossary).
Who owns the elevator interface — the elevator contractor or the access-control integrator?
This is the scope question that most often gets missed in a contract. Salto's integration with TK Elevator illustrates the division: "The ProAccess Space software directly communicates with the keypad, there is no server-to-server integration," meaning the elevator manufacturer's controller has no server of its own in this arrangement — "access plans are defined in the Space software and the communication is established via TKE protocol" (TK Elevator | Salto). That page also states plainly that "specific elevators module license is needed," which is a line-item the access-control integrator and the elevator contractor both need to confirm before bidding — someone has to buy and own that license, and someone has to confirm the car controller runs firmware that speaks the required protocol.
Before construction locks in, have your access-control integrator and your elevator contractor jointly confirm: which party supplies and licenses the elevator-side module, which protocol the car controller uses, whether relays or a licensed digital interface will be used, and who is responsible for commissioning the floor-by-floor test. Cave Group designs guest-room and property access architecture as part of its hospitality technology scope, coordinating that handoff with the elevator trade rather than treating it as an afterthought.
How do floor rights change as a reservation moves through check-in, stay, and checkout?
Floor restriction is only useful if it tracks the reservation, not just the room assignment. In practice this depends on how the PMS synchronizes with the access-control system so that floor permissions are added to a guest's credential at check-in and removed at checkout, matching the existing architecture most properties already use for room-door rights. Salto's glossary defines a "guest" as someone "given a key to allow access for the duration of their stay," and a "guest profile" as a system entry "automatically generated when a room or suite is created" — the same record that should drive which floor outputs or destinations get attached to that guest's credential (Glossary). An "authorization list" is described as "a list of authorization numbers for zones, outputs, and associated devices in a hotel for which guest access is optional," which must be created specifically "if you are using PMS software with the Salto software" — confirm with your integrator that this list is being maintained and reviewed as part of normal operations, not just set once at opening.
Staff and housekeeping floor rights should be modeled separately from guest rights. Salto's glossary distinguishes "users" (generally staff) from "guests" and "visitors" as different cardholder types with their own access levels, so a housekeeper's floor access for an entire wing should not ride on the same output or access-level structure as a single guest's room-floor restriction.
What happens to floor restriction during a fire alarm or a network outage?
Ask your fire-alarm contractor and elevator contractor directly how fire-service elevator recall is wired to interact with any floor restriction imposed by the keycard system — this is a code and life-safety question that sits with those trades, not something the access-control platform's documentation addresses, so it needs a specific answer and a documented test during commissioning rather than an assumption either way.
For network or panel outages, ask how the specific hardware at the elevator relay behaves offline. Salto's documentation notes an important hardware distinction: "Space passcodes only activate relays on the CUC1B0 main unit. Relays on other CUC devices, such as the CUCEB122 secondary unit or the CUCEB004 relay extension board, do not support passcode activation. Elevator implementations that rely on these devices to control floor access require a key, PIN, or other supported credential instead of a passcode" (Outputs in Salto Space). That detail alone is a reason to have your integrator document, device by device, which relay hardware controls which floor and what credential type each one actually requires — a passcode-based assumption that quietly fails on secondary relay hardware is exactly the kind of gap a pre-opening test should catch.
What should be tested before a hotel opens?
Before turnover, the commissioning checklist should cover, per floor and per credential type: that a guest credential activates only its assigned floor buttons and no others, that staff and housekeeping credentials behave correctly across the floors their role requires, that a canceled or expired credential loses floor access immediately, that the fire-service recall behavior confirmed with your fire-alarm and elevator contractors performs as documented, and that the system's behavior during a network outage matches what the relay hardware actually supports rather than what was assumed in the proposal. Document each test by floor, by credential type, and by override mode so there is a record the operator and the elevator contractor both sign off on — not just a general statement that "elevators were tested."
For related rollout sequencing, see SALTO Access Architecture: Reservation to Door, Mapped and Mobile Key: Issue, Revoke & Fallback Acceptance Tests.
Frequently asked questions
Who should own the elevator floor-restriction license — the elevator contractor or the access-control integrator?
Either party can hold the license depending on the project, but it must be assigned explicitly in the contract. Salto's TK Elevator integration confirms a "specific elevators module license is needed," and someone has to be named as the party who purchases, owns, and maintains it.
Does a fire alarm override floor restriction on guest elevators?
This should be asked directly of your fire-alarm and elevator contractors and confirmed during commissioning — the access-control documentation does not describe fire-service recall behavior, so the interaction between recall and floor restriction needs a specific, documented answer for your property rather than an assumption.
Can floor restriction work without a licensed elevator interface?
Yes, using relay-based "outputs" tied to specific floor relays, but Salto's own documentation notes this older method is less common today than its dedicated Elevators license add-on, and not all relay hardware supports every credential type.
How do housekeeping floor rights differ from guest floor rights?
They should be modeled as separate access levels and cardholder types. Salto's platform distinguishes staff "users" from "guests," so a housekeeper covering an entire wing needs a different access-level structure than a single guest restricted to one floor.
What happens to a guest's floor access when they check out?
Floor rights should be tied to the PMS-driven guest profile so they are removed automatically at checkout, the same way room-door access is revoked. This should be confirmed and tested as part of commissioning, not assumed to work by default.