Operate LAN Check-In

Work Through The Task

Use this guide when event work may happen on local devices, offline files, or LAN-only tools instead of the live online dashboard. In this guide, Operate LAN Check-In narrows that work to how onsite operators use EMS LAN for check-in, inclusion claim, inventory, POS, roster, and shifts. Because this is a basics page, read it as part of the EMS LAN learning path rather than as an isolated checklist.

EMS LAN keeps an event moving when internet access is unreliable, but it also creates a second place where event records can change. Read the page for the decision it helps a person make, then use the steps and checks as a steady path from context to action to proof.

What This Task Changes

This is a practical workflow. Read it from top to bottom the first time: the early checks set scope, the middle steps make the change, and the final checks prove the result. The intended readers are Onsite LAN operators and Check-in leads. If the guide names a dashboard route, service area, export, or record type, treat that name as a pointer to real operational responsibility.

• Primary surface or service: /rego/events/manage/check-in?id=:eventId and /rego/events/manage/inclusion-claim?id=:eventId.
• Records or contracts involved: Check-in records, Inclusion claims, and POS records.
• Main care point: Watch for losing track of which file, device, person, or import is trusted while attendee, staff, inventory, POS, or check-in records change offline.
• Proof worth keeping: event ID, snapshot filename, export time, device owner, import summary, sync-history entry, reconciliation count, and supervisor note.

Follow The Work In Order

1. Confirm the exact scope before opening the tool: Begin by naming the EMS LAN situation, the owner, and the exact item involved in Operate LAN Check-In.
2. Read the visible state before editing anything: Use /rego/events/manage/check-in?id=:eventId and /rego/events/manage/inclusion-claim?id=:eventId to connect the words on the page to the screen, file, service route, or record that people actually use.
3. Make only the change this guide describes: Keep Check-in records, Inclusion claims, and POS records in view so the work stays tied to the records or contracts it can affect.
4. Verify the result where another operator would look: Before handing off, save proof such as event ID, snapshot filename, export time, device owner, import summary, sync-history entry, reconciliation count, and supervisor note so the next lead can tell which file and device state are trusted.

Finish With Proof

You are ready to use the rest of this page when the purpose, owner, affected information, and proof are all clear enough for a second person to review.

1. Scope is named: The work is tied to the correct page, event, report, route, file, person, or record.
2. Impact is understood: The operator can explain the effect on offline files, check-in access, staff rosters, inventory counts, POS totals, and import history.
3. Proof is findable: The handoff points to evidence that the next lead can tell which file and device state are trusted.

End-to-end operator runbook

Use this numbered runbook during onsite LAN operation.

1. Step 1 - Start from the live event record. Confirm every LAN device is loaded with the approved file for the correct event ID. This prevents wrong-event operation.
2. Step 2 - Gather prerequisites before touching files or devices. Confirm staff know which flows are active: check-in, claim, inventory, POS, roster, or shifts. This sets expectations.
3. Step 3 - Carry out the operator action slowly. Search or scan each attendee, verify identity and status, then record only the correct onsite action. This changes LAN-local records.
4. Step 4 - Watch for side effects on people and records. Pause when the LAN system shows unpaid, duplicate, cancelled, refunded, transferred, already checked in, or mismatch states. This protects attendee access and records.
5. Step 5 - Verify the result in the right place. At shift changes, compare device counts with the onsite lead’s expected counts. This catches problems before import.
6. Step 6 - Hand off the result with context. When onsite operation ends, return the final LAN file or device to the import owner. This protects the authoritative returned state.

Operator rules

1. Action 1. Verify identity before check-in. Confirm the event ID, file, or device state before continuing.
2. Action 2. Resolve warnings before entry. Check the offline proof before moving on.
3. Action 3. Record claim or POS actions at the time they happen. Keep the sync history or import summary visible.
4. Action 4. Keep devices with assigned operators. Confirm the event ID, file, or device state before continuing.
5. Action 5. Report count mismatches immediately. Check the offline proof before moving on.