How somebody proves who they are at the panel
Five credentials the panel can ask for, plus the option of asking for nothing. What each one needs in place first, and why two panels in the same building can ask for different things.
Before a panel books a room, checks somebody in, or lets them out early, it wants to know who is standing there. Five credentials can answer that, and a sixth option says not to ask.
When more than one is available, the panel offers Choose authentication method first. With exactly one it goes straight into it, and with none it refuses the action outright.
Four methods on this panel, including the one that asks for nothing.
The five credentials
| Method | What the person does | What has to exist first |
|---|---|---|
| Face identification (BETA) | Looks at the panel | A camera on the panel hardware, and up to three photos uploaded in advance by each person |
| QR code | Scans the code on the panel with the Offision app | The app, signed in. The code rotates and expires on a visible countdown, with Generate new QR code underneath it |
| Staff card | Holds their card near the reader | A card reader on the panel and a card registered to them — see Check in by tapping a staff card |
| User passcode | Picks their name, then types a 4–8 digit passcode | The passcode, which each person sets themselves in the user app. Nobody can set it for them |
| Booking pin | Types the pin from the booking | An existing booking to act on — which is why it never appears on a walk-in |
The QR code is the one people get backwards. The panel shows the code and the person scans it with their phone; the panel is not reading a code off their screen. Whether it renders Black & white or Colorful is a setting beside the method itself.
User passcode always takes two steps, because the passcode alone does not say whose it is. Where the action has a booking attached the panel already knows the candidates; on a walk-in it has to search everybody.
Name first, passcode second — shown here with Mask part of user name from search list on.
Asking for nothing: Allow anonymous
Allow anonymous adds a Use directly tile. Taking it creates the booking with no organiser at all — the room is held, and nothing records who took it.
Two limits are worth knowing before turning it on:
- It only ever appears on booking-type actions — walking in, booking ahead from the panel, taking a seat. Checking in, checking out, extending and cancelling always ask for a credential, because those act on somebody else’s booking.
- It lives only on a panel configuration. There is no organisation-wide equivalent, which is deliberate: anonymous suits a phone booth or a touchdown desk and suits almost nothing else.
Where the methods are set
Two screens, and the second overrides the first.
Check-in method sets the default for the whole organisation — QR code, Staff card, User passcode, Booking pin and Face identification, with Enable at least one of the following check-in methods on the device. Any panel with no override of its own follows it. See Checking in at the booking panel, which shows that screen.
Open Check-in methodOverride the system user identification settings, on a panel configuration’s Check-in method page, is what lets panels differ — “By overriding the system settings, each device can be configured with a different identification method.” A panel in a secure area can insist on a staff card while the one in the open-plan corner accepts a passcode.
Open Panel configurations
The override, with Allow anonymous underneath the methods it applies to.
Two things do not follow the override:
- Booking pin is not on the per-configuration list at all. A panel takes it from the organisation-wide screen whatever its configuration says.
- Face identification still needs a camera. Turning it on for a panel that has none simply leaves the tile off that panel.
What this does not control
- Whether the person is allowed to do the thing. Identifying successfully and being permitted to book, check in or extend are separate questions — the second is the resource’s policy and their permissions.
- The passcode itself. Each person sets and changes it in the user app.
- Opening the door. Where a panel drives a lock, unlocking rides along with the action; a panel with no access hardware still identifies people perfectly well.
- Which buttons the panel offers. That is the configuration’s Function page — see Let somebody take a free room at the panel.