Incident Reporting

OverviewCopy Anchor Link

The incident reporting system lets you document safety issues, near-misses, maintenance needs, guest complaints, and stockouts the moment they happen. Reports carry severity, type, ownership, visibility, and an audit trail from submission through closure. Notifications fan out to Slack through a deduped notification queue, and an isInventoryAlert flag on stockout incidents bypasses the standard priority gate so they reach managers faster.

The Operations Inbox (/inbox) presents the incident triage panel with summary chips (open · critical/high · aging · unassigned) and a scannable list of incident entries showing severity rail, owner, age, and status. Filter chips (Open, Aging, Critical, Assigned) persist in the URL. The legacy /incidents list path redirects here.

Filing a ReportCopy Anchor Link

Open Incidents in the sidebar and tap Report Incident. The form is split into four progressive sections — Details, Severity, Description, Contact (optional) — with a section-progress rail at the top so you can see what's left.

1. Details — Date, shift (Lunch, Dinner, or Late Night), and type. The date and shift default to today and the current shift, which you can change for retroactive reports.
2. Severity — Pick one of low, medium, high, critical. If you choose critical, a confirmation dialog appears so you can double-check — most critical reports also fire urgent notifications.
3. Description — Notes (1–5000 chars, required) and optional photo or video attachments. Attachments use the shared uploader, which auto-converts HEIC photos to JPEG and caps each side at 1920px.
4. Contact (optional) — Attach an existing contact from the directory, or capture a new one (name required, plus phone/email/notes as available). Skip this section entirely for incidents that aren't tied to a person.

You can dictate the description with the Dictate button — the browser's voice-to-text fills the notes field as you speak.

Your work autosaves as an identity-safe draft on your device (clearing any client-provided identity fields). A recovery banner offers to restore your draft if you return to a half-finished report. Upon successful submission, saved draft state clears automatically.

Incident TypesCopy Anchor Link

SeverityCopy Anchor Link

The priority number (1–3) is auto-derived from severity but admins and managers can override it from the incident detail.

Status LifecycleCopy Anchor Link

Incidents move through four statuses with explicit transitions:

Each transition writes an incident.status_changed audit entry and dispatches a notification (if the destination is resolved / deferred / reopened).

OwnershipCopy Anchor Link

An incident is ownerless until someone claims it. From the detail page (admin/manager only):

• Claim Owner — assigns the current user as owner.
• Reassign Owner — pick any admin or manager at the location. Owners are auto-assigned when a manager moves the status from reported to investigating.
• The owner's name appears on the incident card and in the notifications.

VisibilityCopy Anchor Link

Every incident is either:

• Manager Only (default) — visible to admins and managers at the location, plus the reporter.
• Employee Visible — also visible to non-management staff at the location. Useful for hazards that the whole team should be aware of.

Toggle visibility from the detail page when you have management access.

PriorityCopy Anchor Link

Priority (P1 / P2 / P3) is auto-set from severity. Admins and managers can override it from the detail page. Escalating an incident automatically bumps the priority (P2 → P1, P3 → P2; P1 stays at P1).

EscalationCopy Anchor Link

Escalate from the detail page when an incident needs wider attention. Escalation requires a short note explaining the reason. Each escalation:

1. Adds an incident_escalations row with the notes, the escalator, and a timestamp.
2. Bumps the priority if it isn't already at P1.
3. Sends an urgent Slack notification to the team room.
4. Marks the incident as "Escalated" in the list and on the detail card.

Resolved incidents cannot be escalated — reopen them first if needed.

CommentsCopy Anchor Link

Anyone who can read an incident can comment. Comments are free-form (1–2000 chars), timestamped, and labeled with the author's display name. The list appears on the detail page in chronological order, with the comment form pinned to the bottom for management views.

Source MessagesCopy Anchor Link

Incidents can be created from a phone message if a guest call or in-person message escalates into a real issue. The reverse link is preserved: the source message shows up in the incident's "Source Messages" card, and the message detail page lists any incidents created from it. Use this to keep the narrative in one place instead of duplicating it across two records.

NotificationsCopy Anchor Link

Every incident event dispatches through the notification_queue worker:

The Slack template (buildIncidentBlocks) renders Acknowledge, Escalate, and View Details buttons; click Acknowledge to mark the incident as investigating from Slack.

Audit TrailCopy Anchor Link

Every change is written inside the same database transaction as the mutation, so the log never drifts from the data:

• incident.created
• incident.status_changed
• incident.escalated
• incident.comment_added
• incident.owner_changed
• incident.priority_changed
• incident.visibility_changed

View the full history per incident from the detail page's Status History section, or browse the team-wide log at Admin → Audit Log.

RelatedCopy Anchor Link