/ to search
Documentation Check In Attendance

Check In Attendance

Check-in & Attendance Reference

Browse tenant guides generated directly from the Markdown files in docs/tenant.

Overview

This reference lists the confirmed staff-facing areas, attendance fields, scanner behavior, and operational notes for event-day check-in.

Use this page when you need a quick reminder of:

  • where attendance work happens
  • what an attendance record includes
  • how the scanner validates scans
  • what results staff should expect during check-in

Staff-facing areas

Attendance-related areas include:

  • Check-in scanner page
  • event Attendance relation
  • attendance export
  • badge PDF generation

These surfaces support both live event-day operations and post-event attendance review.

Attendance record fields

Attendance records can include:

  • attendee name
  • type: registrant or guest
  • checked-in timestamp
  • checked-in by
  • source: qr scan, manual, or import

Field guidance

Attendee name

Identifies the person who was checked in.

Type

Helps distinguish between a primary registrant and a guest attendee where relevant.

Checked-in timestamp

Records when the attendance action occurred.

Checked-in by

Shows which staff user performed the attendance action where applicable.

Source

Indicates how the attendance record was created, such as QR scan, manual handling, or import.

Scanner behavior

Confirmed scanner behavior includes:

  • event must be selected first
  • QR token must belong to the selected event and tenant
  • already checked-in scans return a success-style confirmation rather than creating a duplicate
  • invalid, expired, wrong-event, or wrong-tenant tokens are rejected

Scanner interpretation notes

Event must be selected first

The scanner works in the context of one selected event. This keeps the result tied to the correct operational record.

Token must belong to the selected event and tenant

This helps prevent staff from accidentally checking someone into the wrong event or using a code from another tenant context.

Already checked-in behavior

If an attendee has already been checked in, the scanner returns a confirmation-style result instead of creating another attendance record.

This is intentional and helps door staff handle repeat scans without confusion.

Invalid, expired, wrong-event, or wrong-tenant tokens

These are rejected to protect attendance accuracy.

Fallback behavior

The scanner page includes a mobile-friendly fallback for pasted codes such as CHK1:....

This is useful when:

  • the camera is unavailable
  • a QR code cannot be read
  • the attendee presents the raw code value
  • the event team needs a second path under busy conditions

Attendance and registration are different

Attendance is separate from registration status.

This matters because:

  • a confirmed registrant may never arrive
  • a guest may be checked in separately
  • a no-show analysis depends on attendance, not only registration
  • follow-up communications may need attendee-only or no-show-only logic

Badge generation

Badge generation is confirmed in code and supports event-day identity handling.

Badge layout details should be treated as operational rather than supporter-facing, since print workflow and layout use may vary by event team.

Operational notes

  • Attendance is separate from registration status.
  • The scanner page includes a mobile-friendly fallback for pasted codes.
  • Badge generation is confirmed in code, but tenant docs should treat layout details as operational rather than donor-facing.
  • Attendance exports are useful after the event for follow-up, reconciliation, and reporting.

Example event-day usage

A front-desk team may use:

  • the scanner page for live arrivals
  • the pasted-code fallback when a QR code does not scan
  • the attendance relation to confirm who has arrived
  • the attendance export after the event for no-show and attendee follow-up analysis