Local Admin and Control Room

Use This Dashboard Area Safely

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, Local Admin and Control Room narrows that work to how to operate Control Room, local user accounts, machine tokens, native diagnostics, and admin-only LAN features. Because this is a surfaces 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 The Screen Controls

This page explains a specific surface. Treat every button, field, filter, and table as a way to view or change real records, not just as a visual layout. The intended readers are LAN admins and Server operators. 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: /control-room, /admin/:eventId/local-users, and /admin/:eventId/machine-tokens.
• Records or contracts involved: Local user accounts, Machine tokens, Native capability state, and HTTPS status.
• 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.

Read The Screen From Top To Bottom

1. Confirm you are on the right event, report, route, or file: Begin by naming the EMS LAN situation, the owner, and the exact item involved in Local Admin and Control Room.
2. Read the current state before changing it: Use /control-room, /admin/:eventId/local-users, and /admin/:eventId/machine-tokens to connect the words on the page to the screen, file, service route, or record that people actually use.
3. Use the smallest action that matches the task: Keep Local user accounts, Machine tokens, Native capability state, and HTTPS status in view so the work stays tied to the records or contracts it can affect.
4. Check the list, detail view, history, or public page afterward: 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.

Before You Leave The Screen

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 for LAN-only administration.

1. Step 1 - Open the exact screen for the event. Sign in as a local admin and confirm the imported event. This proves you have authority for admin-only actions.
2. Step 2 - Identify what the screen reads and writes. Decide whether you are checking runtime health, creating a local user, minting a machine token, diagnosing Android/native state, or managing communications calls. This prevents accidental admin changes.
3. Step 3 - Use one control at a time. Use Control Room, Local User Accounts, or Machine Tokens to complete the specific task. This changes local runtime or access records.
4. Step 4 - Check who or what was affected. Confirm each user, token, or diagnostic action is scoped to the event and does not expose broader access. This protects the LAN system.
5. Step 5 - Confirm the screen and history agree. Test the created account or machine token with the intended route. This proves access works and is scoped.
6. Step 6 - Leave notes another operator can follow. Revoke unused tokens, disable stale users, and record device ownership. This keeps local admin state clean.

Admin surfaces

Surface	Purpose
Control Room	Runtime, native, server URL, HTTPS, and diagnostics entry point.
Local User Accounts	Create, update, delete, and seed operator credentials.
Machine Tokens	Create, update, revoke, and copy event-bound API tokens.
Communications admin tools	Audit, debug, force-end calls, and manage event communications where available.

Stop conditions

1. Question 1. Does this action grant access? Write the answer before choosing the next action.
2. Question 2. Is the access scoped to the correct event? Write the answer before choosing the next action.
3. Question 3. Can the token or account be revoked if the device is lost? Write the answer before choosing the next action.