Checking in by QR code, and proving you are there
One scan does different things depending on what the room is doing. GPS is not a way of checking in — it is a condition on checking in from the app.
There are two different QR codes
They look the same and behave differently, which is most of the confusion here.
The code on the panel’s screen changes with the room. Its caption reads Scan to check-in while a booking is waiting, Scan to extend / check-out while one is running, and Scan to book while the room is free.
The printed sticker on a door or a desk is a fixed code for that resource, and it does all four jobs on its own — check in, walk in, extend, check out. Stickers can be downloaded and printed per resource or in bulk, and regenerating one invalidates whatever is already stuck to the furniture.
A resource's sticker, and the list of what scanning it can do.
One scan, several outcomes
Scanning does not mean “check in”. It means “tell me about this resource, and do the obvious thing” — and the obvious thing depends on the room and on who is holding the phone:
- The room is free — the walk-in form opens.
- The room is yours and waiting — you are checked in, with no further tapping.
- The room is yours and running — the booking opens, so you can extend or end it.
- The room is somebody else’s — you are told so, and nothing happens.
- The room is out of hours or out of service — refused, with the reason.
GPS is a condition, not a method
Turning on Require GPS check-in does not add a way to check in. It adds a test that app check-in has to pass first: the phone must be within Allowed distance of the building.
The circle is drawn around the building, not the room — so a building with no location refuses everybody.
Three consequences follow from where that circle is centred:
- It is the building’s location, not the room’s. Every resource in a building shares one circle.
- A resource whose building has no location cannot be checked into at all once this is on. The settings page counts them for you and names them, because this fails closed rather than falling back.
- The radius is a floor, not a preference. It cannot be set tighter than 50 metres, and defaults to 200 — a phone’s idea of where it is has a margin, and a circle drawn inside that margin refuses people who are standing in the room.
There is no proceed-anyway. The confirm button stays inactive until the phone is inside the circle, which is the whole point — a bypass would make the setting decorative.
What the mobile app actually adds
The screens are the same ones as in a browser — the mobile app is a shell around them. What it supplies is the two things a browser on a phone cannot reliably give: a camera for scanning, and a location the operating system will vouch for. That is why GPS check-in is dependable in the app and unavailable in some browsers.
If a check-in fails there, the useful question is which of the two was refused — camera permission or location permission. They are separate prompts and either can be off.
Forcing on-site check-in without GPS
User Portal check-in IP restriction accepts app check-in only from the addresses you list. It is cruder than a geofence — it proves which network, not which place — but it needs no permission prompt, no location hardware, and works inside Teams. Many organisations find it enough.
What it does not control
- The panel’s own methods. Staff cards, passcodes and face are asked for at the door, and are unaffected by any of this — see Checking in at the booking panel and Check in by tapping a staff card.
- Whether the app shows a check-in button at all. That is Show check-in button in User Portal, and it is also the setting that makes no-show figures questionable — see What counts as a no-show.
- Whether attendees may do this. The app grants attendees check-in by QR only, under a separately named policy toggle from the panel’s.
- The check-in deadline. Scanning inside the window checks you in; scanning after it finds the booking already gone — see How check-in and no-show work.