Where a card number is read, and what a tap does there
One card number is read by room panels, desk panels, the attendance clock, the problem-reporting screen, event panels, a phone wallet and the API. What each of them does with it, and the one rule they all share.
A card number is stored once and read in a lot of places. Every one of them does the same first thing — turn the number into a person — and then does its own job as that person. Nothing about the card decides which job; the screen it was tapped at does.
This page is about what a tap does. To find out what number a particular card sends — so you can store it against somebody — see Read a card number at the panel.
Everywhere a tap is read
| Where | What the tap does |
|---|---|
| A room booking panel | Checks the person into the booking that is waiting, starts a walk-in on a free room, or offers extend and check-out during a meeting — see Check in by tapping a staff card |
| A panel wired to a lock | Opens the door alongside the check-in, where the room has the hardware — see Connect an AXIS door lock |
| A desk or seat panel | Claims the seat the person booked |
| The attendance clock | Records a clock-in or clock-out — see How attendance works |
| Report a problem at a panel | Signs the report so the queue knows who raised it — see Report a problem at the room panel |
| An event panel | Marks the person present at the event |
| A phone in a wallet | A user mobile pass carries the same number over NFC, so a phone taps where a card would |
| The External API | Stores and clears numbers from another system — see Open a meeting room door from a booking |
Cards are one of several ways to say who you are at a panel; the others are a QR code, a passcode and a booking PIN. Which of them a panel offers is set in Booking, not here — see Identify at the panel.
The rule they all share
Every one of those screens resolves the card through the same step, so the same three things are true everywhere:
- An unknown number does nothing, silently. No message, no flicker. A panel in a corridor that complained about every card carried past it would be unusable — so a card from another building is simply ignored.
- The first number that resolves wins. Some readers send more than one identifier for one physical card; the panel tries them in the order they arrived and stops at the first that finds somebody.
- Case does not matter. A number enrolled in lower case matches a reader sending upper case.
A card outlives the account
Deactivating somebody does not touch their card. The number still resolves at every screen above, so a card left in a wallet still names them at a panel after they have been stopped from signing in.
Deleting them is not the answer either, though it behaves differently: with no account left to resolve to, the number goes quiet at every screen — but it is still reserved, so it cannot be issued to anybody else, and it comes back the moment the person is restored from the recycle bin.
Stopping the card is its own action, and the only one that both silences the number and releases it: clear it on the person’s record — see Remove someone who has left.
What never reads it
- Signing in to Offision. The apps and the console take a password, a passcode or your company’s sign-in. No screen anywhere accepts a card.
- Your building’s own access-control system. Offision does not send card numbers to a door controller. A panel wired to a lock opens it because Offision told the lock to open, not because the controller recognised the card.
- Visitor check-in at the lobby. A visitor has a badge or a wallet pass of their own — see What appears on a visitor badge.