Track event attendance in Airtable

Outcome and scope

Separate registration from actual attendance. Staff should be able to count arrivals while still accounting for cancellations and later check-ins. Build a minimal reception view that contains only what desk staff need, and retain contact details in a more restricted management area. A registration confirmation is not proof that a person entered the venue.

The reception ID should match the invitation. Define how staff handle a typo, substitute attendee or replacement badge without creating another active registration.

Prepare the fields and destination

Prepare these fields: Event ID, reception ID, display name, registration state, attendance state, check-in time, desk operator and cancellation reason. Keep source values separate from a reviewer’s confirmed values, and do not reuse an existing column for a different meaning. Create the first record with practice identifiers in a destination whose read and edit access matches the intended staff roles. Inspect the saved result from that role before using live information.

For multi-session events, distinguish entering the venue from attending a particular session. Track a person-session relationship only when the operation can actually capture it reliably.

Build the workflow in order

Link registrations to an event and map each registration to a reception identifier. Decide how group registrations become individual attendance counts. Names alone can collide, so desk staff should primarily search by reception ID and use another permitted field for confirmation when necessary.

Create an event-specific reception view showing eligible registrations and check-in state. Record an arrival only when the desk verifies it, including time and operator. Define re-entry as a separate observation on the existing attendee where required, rather than creating another registration that inflates attendance.

After the event, reconcile registered, cancelled, arrived and unresolved counts separately. Mark walk-ins with their origin so they are not mistaken for missing imported applications. Remove temporary reception access and apply the agreed retention process to contact information and supporting materials.

Work through a small example

Test three registrations: one cancelled, one checked in and one not yet arrived. The total should be three, eligible attendance two and actual arrivals one. Search the checked-in identifier again and verify staff see its existing state instead of creating a second arrival.

Handle changes during operation

Give reception staff the minimum necessary roster. Publicly naming attendees is a separate use from running a desk and should not be inferred from the existence of an internal attendance record.

Estimate cost and usage

Estimate annual events, registration rows, attendance events and desk access requirements. Review how temporary reception staff obtain the minimum access they need. Notifications or external readers may add separate fees and integration usage. Include staffing at peak arrival times and the offline fallback so the budget reflects the event operation, not just its database.

Investigate failures

Plan an offline fallback before doors open. If staff record arrivals on paper during an outage, reconcile those entries with online records afterward, preserving the time and operator. Keep the backup roster under event control rather than sending personal information to private devices or an unrestricted chat.

Review before release

Before release, test a normal record, one missing a required value, a repeated identifier and an edited record. Use event id to trace the saved result back to the source. The acceptance condition is: Separate registrations from arrivals and prevent re-entry or cancellation from distorting counts. Record the expected result before testing, compare it with the actual saved state, and resolve unexplained differences before increasing the scope.

• Create an Airtable intake register
• Assign Airtable form responses
• Views for open work