Check-in

Check-in happens at a CheckInSession: a named checkpoint that admits certain Passes from one or more Events. A CheckIn records that one Participant arrived at that checkpoint. This page explains how a session is set up, how a scan is judged, and why the same person cannot enter twice at the same door.

• Owned by

  One Organization

  It can span several Events

• Accepts

  All Passes, or a chosen list

• States

  Active, paused, closed

• Window

  Optional open and close times

• Duplicates

  One per Participant per session

  Enforced by the database

• Needs network

  Yes

  There is no offline acceptance

What a session isCopy Anchor Link

A session has a name, optional instructions, an optional location, and an optional opening window. It covers at least one Event and either every Pass of those Events or an explicit list of Passes drawn from them.

The Pass list is the authority. A Pass that is not accepted here is refused even when the person and their Registration are otherwise fine. That is what lets you run a workshop-room desk that only admits the workshop Pass without creating a second Registration.

Typical sessions are a main gate, a workshop room, a kit desk, and a meal counter. The same Participant can be admitted at every one of them. Each session is a separate fact, and the main gate does not imply the meal counter.

One arrival per person per doorCopy Anchor Link

A successful CheckIn is unique for a Participant at a session. The database enforces it, not the scanner's memory.

Two volunteers scanning the same person at the same moment produce one CheckIn. The second device is shown Already Checked In, with the original time and the operator who admitted them. That is a correct result, not an error.

If a venue genuinely scans twice at one entrance, for example an outer gate and an inner hall, create two sessions. Two sessions are two checkpoints; one session is one arrival.

What a scan checksCopy Anchor Link

A scan is accepted only when every one of these holds:

1. The Organization and session match, and the Registration's Event is covered.
2. The session is active and inside its window.
3. The credential signature is valid and its version is current.
4. The Registration is confirmed and the Participant is active.
5. The Pass is accepted here and has not been cancelled.
6. The newest approval, when the Pass requires one, is approved.
7. The Registration form and the personal form are submitted, and the person has a name.
8. Every applicable hard Requirement at the check-in gate is satisfied.
9. No CheckIn already exists for this person at this session.

If any check fails, no CheckIn is written. The attempt is still recorded.

What the volunteer seesCopy Anchor Link

The scanner uses colour, sound, and vibration to separate a yes from a no. Every result has a plain label.

Scanning and manual entryCopy Anchor Link

The scanner opens in fullscreen, keeps the screen awake, and can scan with the camera. It also accepts typed details: an email, a phone number, or a name.

• Typed input needs at least 3 characters in the scanner.
• A search can return several candidates, and the operator picks one.
• A successful manual admission is recorded with the manual method.
• Auto-advance returns after 5, 10, or 15 seconds, or waits for a tap.
• An identical scan within 3 seconds is ignored, so one QR is not submitted twice.

The scanner needs a connection. When the device goes offline, an overlay blocks scanning; when the server is unreachable, the page says so and pauses. There is no queue of offline admissions to reconcile later.

Every attempt is recordedCopy Anchor Link

A ScanAttempt is written for every scan or lookup, accepted or rejected. It stores the session, the operator, the device label when supplied, a fingerprint of the presented value, the result code, an optional reason, and the time. The raw QR is never stored.

This is what makes a rejection explainable later. The session page shows recent attempts, and the Organization-wide log lets you filter by session, Event, Pass, person, and time.

A successful CheckIn is written in the same transaction as its attempt. If the attempt row cannot be written, the admission does not commit.

Live countersCopy Anchor Link

Each session shows two numbers. Admissible counts active Participants on confirmed Registrations whose Pass this session accepts. Checked in counts the CheckIn rows for this session.

They answer different questions. A person can be admissible without arriving, and a person who arrived stays counted even if their Registration is later cancelled.

What is not availableCopy Anchor Link

• There is no undo or delete for a CheckIn. A wrong admission stays in the record.
• There is no offline mode or later reconciliation.
• There is no way to admit one person twice at one session; create a second session instead.

RelatedCopy Anchor Link

• Credentials — what the QR contains and how it changes
• Troubleshooting — what to do for each rejection
• Registrations — the entry being admitted
• Requirements — the check-in gate
• Run Check-in — the organizer walkthrough