Event Check-In: A Registration Is Not Evidence That Someone Arrived

An event check-in app should answer two different questions: may this registration be admitted, and has someone already used it to enter? A booking confirmation alone does not record arrival. Agree the admission rule before choosing a badge scanner.

This is a guide to briefing an entrance workflow, not selling tickets or allocating a waiting-list place. The recommendations below need testing in your implementation; they are not guarantees about every event platform.

Decide what the desk records

Choose the unit of attendance. Is one registration for one person, a group, or several sessions? A group leader arriving should not automatically mark absent colleagues as present unless that is genuinely the agreed reporting rule. If staff need partial group arrival, make that an explicit requirement.

The Odoo 19 Registration Desk documentation provides a concrete example: scanning a valid badge grants event access and logs attendance. It also supports manual attendee selection. That illustrates an arrival action separate from registration, but does not establish your rules for identity checks, repeat entry or group attendance.

Avoid a single label such as “valid” that hides the distinction. Staff need the event, applicable session or ticket scope, current eligibility and existing attendance information needed for their decision. Show only the personal information required at the desk.

A readable badge is not the whole decision

Specify what happens to a code for the wrong event, a cancelled registration or a ticket already presented. Reading a code successfully should not by itself produce a green admission message. A copied badge also does not prove who is holding it. If the event needs an identity check, define a separate, appropriately reviewed process rather than claiming the scanner provides one.

For a fictional workshop, two entrances may scan the same registration at nearly the same moment. If your policy permits only first admission, ask the developer to demonstrate one successful arrival and one clear already-used result. This is a requested concurrency outcome, not a capability established by the Odoo source.

Decide whether leaving and returning is allowed. A permitted return visit should not inflate the number of unique attendees. If you need an occupancy count, exits and re-entry require their own agreed recording process; a list of arrivals alone is not that count.

Give manual lookup the same rules

A broken camera or damaged badge needs a practical fallback. Odoo documents a manual list that can include registered attendees across events in the database. For your app, require the selected event to be unmistakable and define who may search or override an admission decision.

Manual selection should apply the same eligibility and already-used rules as scanning. Do not turn a fallback into an unrestricted “let anyone in” button. If an authorised override is necessary, preserve its reason and responsible operator without silently rewriting the original registration.

Also decide what a connection failure means. Is admission paused, handled by a documented manual process or supported offline under explicitly tested reconciliation rules? The cited documentation does not certify offline admission. Do not promise it merely because the scanner opens on a phone.

Test the queue and the report together

Use synthetic registrations for the acceptance demonstration. Include a first arrival, a repeat scan, the wrong event, a cancelled registration, a partial group and a manual lookup. Test competing scans from separate devices and the agreed connection-failure procedure.

Inspect the report afterwards. It should distinguish registrations, unique arrivals and any repeat-entry activity according to your written definitions. An authorised correction should explain an erroneous check-in rather than leave staff guessing why totals changed. None of these counts alone establishes continuous presence or proves identity.

When discussing a custom business app, bring the admission policy and a sample entrance shift. A useful deliverable is a demonstrated decision and an intelligible attendance record, not just a fast scan animation.