Start the LAN App

Overview

Start the LAN App: How to start FPH LAN EMS, sign in, import an event, and give operators the correct local URLs. This page is written for event leads, LAN operators, check-in staff, POS staff, roster leads, local admins, and support reviewers, so it uses operational language: what the area is for, what can change, what can go wrong, and what proof another reviewer should expect.

EMS LAN work should be treated as an accountable handoff, not as a private technical action. The source context for this page is fph-lan-ems, partner dashboard Offline Snapshot and Sync History, EMS LAN support routes, and the completed EMS LAN task history.

Scope

Area	What this page covers
Product area	EMS LAN
Docs stage	Basics
Practical scope	snapshot export, file custody, schema metadata, import validation, warnings, and applied counts
Primary outcome	keep an event operating on a trusted local network when internet access is unreliable, then return offline work to the online dashboard with reviewable proof

Routes and surfaces

Route or surface	Why it matters	Verification proof
/login	Surface, route, host, or integration context readers should have open while following this page.	Confirm the page, host, event, environment, or integration is the one currently being reviewed.
/control-room	Surface, route, host, or integration context readers should have open while following this page.	Confirm the page, host, event, environment, or integration is the one currently being reviewed.
/admin/:eventId/:surface	Surface, route, host, or integration context readers should have open while following this page.	Confirm the page, host, event, environment, or integration is the one currently being reviewed.
/workspace/:eventId/:surface	Surface, route, host, or integration context readers should have open while following this page.	Confirm the page, host, event, environment, or integration is the one currently being reviewed.

Page-specific records

Record or contract	What it represents	Verification proof
Local SQLite database	Record or contract family that can be read, exported, changed, imported, reconciled, or used as support evidence.	Keep the record ID, count, status, timestamp, or owner needed for another reviewer to verify the handoff.
Bootstrap credentials	Record or contract family that can be read, exported, changed, imported, reconciled, or used as support evidence.	Keep the record ID, count, status, timestamp, or owner needed for another reviewer to verify the handoff.
Imported events	Record or contract family that can be read, exported, changed, imported, reconciled, or used as support evidence.	Keep the record ID, count, status, timestamp, or owner needed for another reviewer to verify the handoff.
Local sessions	Record or contract family that can be read, exported, changed, imported, reconciled, or used as support evidence.	Keep the record ID, count, status, timestamp, or owner needed for another reviewer to verify the handoff.

Decision owners

Audience	Responsibility	Verification proof
Server operators	Reader group expected to make or review decisions from this page.	Make sure this group has the required access and escalation path before relying on the workflow.
Event leads	Reader group expected to make or review decisions from this page.	Make sure this group has the required access and escalation path before relying on the workflow.
LAN admins	Reader group expected to make or review decisions from this page.	Make sure this group has the required access and escalation path before relying on the workflow.

Mental model

The safe way to use this page is to follow the record, not the screen. A screen, route, file, or response is useful only when staff can connect it to the actor who used it, the record it changed, and the proof that remains afterward.

Use this sequence before relying on the page:

1. Identify the exact event, route, file, account, device, or record family.
2. Confirm which system is the source of truth at this step.
3. Check the role, local account, attendee account, machine token, or service caller.
4. Make the narrowest action that matches the workflow.
5. Verify the result where the next reviewer will look.

Inputs, options, and records to check

Shared item	What it means	Verification proof
Snapshot file	Carries event data into or out of the offline environment.	Event ID, export time, format, file owner, and import history match.
Local SQLite records	Hold LAN-local check-in, claim, POS, inventory, HR, roster, communications, account, and token state.	Local counts are compared to online records after import.
Operator or device identity	Shows who acted in the local environment.	Local user, machine token, Android device, or server operator is named.
Exception notes	Explain manual decisions made while disconnected.	A later reviewer can identify what happened and who owns follow-up.

Operating sequence

Step	Action	Stop if
1	Confirm scope before acting.	The event, file, route, environment, user, or device is unclear.
2	Check authority before changing state.	The actor can view information but should not make this decision.
3	Review the visible option, file, route, or record effect.	The action affects access, money-adjacent records, public information, offline state, or external services without a reviewer.
4	Complete the action only after the expected result is known.	Staff cannot say what success and failure should look like.
5	Save handoff evidence.	The result exists only in memory, chat, or an unsafe screenshot.

Flowchart

flowchart TD
  prepare["<b>Prepare online</b><br/>Confirm event setup, regos, staff, inventory, and roles<br/><i>Docs: Pre-Event Readiness</i>"] --> export["<b>Export snapshot</b><br/>Create the event file and record custody<br/><i>Docs: Export LAN Snapshot</i>"]
  export --> operate{"Operate locally?"}
  operate -- Yes --> lan["<b>Run EMS LAN</b><br/>Use local check-in, claims, POS, inventory, HR, and communications<br/><i>Docs: Operate LAN Check-In</i>"]
  operate -- No --> hold["Hold the file and fix readiness gaps"]
  lan --> import["<b>Import returned file</b><br/>Validate event identity and apply local changes<br/><i>Docs: Import LAN Snapshot</i>"]
  import --> reconcile["<b>Reconcile</b><br/>Compare imported counts, notes, and money-adjacent records<br/><i>Docs: Reconcile After Import</i>"]
  click prepare "/ems-lan/basics/pre-event-readiness/" "Open readiness guide"
  click export "/ems-lan/basics/export-lan-snapshot/" "Open export guide"
  click lan "/ems-lan/basics/operate-lan-check-in/" "Open operation guide"
  click import "/ems-lan/basics/import-lan-snapshot/" "Open import guide"
  click reconcile "/ems-lan/basics/reconcile-after-import/" "Open reconciliation guide"

Verification

Check	Evidence to keep
Scope check	Event ID, route family, file name, record ID, environment, account, or device name.
Actor check	Staff role, attendee account, local user, machine token, service caller, or external system.
Result check	Updated record, imported count, response body, audit entry, local note, sync-history row, or visible status.
Exception check	Warning, skipped row, validation error, denied permission, partial result, or fallback decision.
Handoff check	Named owner and next action for anything unresolved.

Common mistakes

Mistake	Why it causes problems	Recovery
Treating a visible screen as complete proof.	Screens may be filtered, stale, local-only, or scoped to one actor.	Check the underlying record, route evidence, sync history, or audit trail.
Acting without naming the actor.	Permissions and side effects depend on who or what made the request.	Repeat the check with the correct staff role, attendee account, local user, or service caller.
Skipping evidence because the action looked successful.	Support cannot distinguish success, partial success, retry, or workaround later.	Capture timestamp, record ID, result, and reviewer note before closeout.

Related pages

• Pre-Event Readiness
• Export LAN Snapshot
• Operate LAN Check-In
• Import LAN Snapshot
• Reconcile After Import
• EMS LAN Data Records