How check-in and no-show work

Check-in is the step that turns a booking into a room somebody is actually using. Where a resource requires it, a booking that nobody checks into is recorded as a no-show and the room is given back.

The timer is not called what you expect

There is no setting named “auto-release”. The deadline is a field called Can check-in after (in mins), in the Check in/out group of the resource’s policy. It is written as a permission — how late somebody may still check in — and it is the same number that decides when the room is taken away.

Nothing happens at all unless Require check-in is on. With it off, the system checks the booking in on the organiser’s behalf and the room is held for the full booked period — which is why an unattended booking on a relaxed policy looks like a fault and is not one.

The window, and where it closes early

Both numbers are measured from the booking’s start time — one backwards, one forwards.

Three things close it earlier than the arithmetic suggests:

• The booking’s own end time wins. A 10-minute booking on a policy with a 15-minute grace has a 10-minute window, not 25.
• All-day bookings ignore the window entirely when All-day booking check-in time is set, and use that clock time as the deadline instead. A midnight start makes a window measured in minutes meaningless.
• A booking on several resources takes the strictest policy. The smallest before and after values across every resource in the booking are the ones that apply.

Releasing is a real release

A no-show is not only a label. The resource’s reserved period is shortened to the moment of release, so the rest of the slot is genuinely free and shows as free everywhere. On a room synced from Microsoft 365 or Google, the shortened period is pushed back to that calendar too.

Checking in rewrites the booking the same way, in the other direction: check-in moves the start to now, and checking out moves the end to now. The record ends up describing what happened rather than what was booked, which is what makes the usage figures worth reading.

Nobody has to be watching

The system writes to the organiser at both ends of the window — a Waiting for check-in reminder when the resource becomes available to check into, and a No-show email reminder when it is released — with matching notifications in the app. Both can be switched off for the whole organisation.

That matters when you are deciding how tight to make a window. A ten-minute grace that nobody is warned about feels arbitrary; the same ten minutes with a reminder at the start of it is a fair warning.

Two more behaviours worth knowing

• Walk-in bookings never require check-in. Somebody standing at the panel claiming a free room has already proved they are there.
• A repeating series can cancel itself. Where Cancel recurring booking after consecutive no-shows is on, a series that is abandoned often enough has its remaining occurrences cancelled, and the organiser is warned one no-show before it happens.

What it does not control

• Quota is not refunded by a no-show. The booking is released, the charge is not. Only cancelling returns quota, and only inside the refund deadline — see Booking rules reference.
• The booking release schedule is a different feature. It decides when a future period opens for booking. It has nothing to do with releasing an unattended room, despite the name.
• Early check-out and extend are their own policy settings, and neither is affected by the check-in window.
• Who may press the button is decided per method — at the panel, in the app, by a sensor. Each has its own article.

Where check-in can happen

• At the booking panel — the only method that proves somebody was at the door.
• By QR code, and GPS — scanning a code, and proving you are near the building.
• What counts as a no-show — once it has happened, what the reports say about it.