Check-in workflow

The queue behind the Check-in screen — the workflow it runs on, what each host action writes, the notifications it sends, and the other pipelines the platform creates for you.

The Check-in screen is not a list of reservations. It is a list of tasks on a workflow called reservation-checkin-pipeline. Understanding that explains everything the screen does: why a walk-in and a booking look the same in the queue, why Assign moves a party off it, and why a no-show changes the booking.

The pipeline

The workflow has two stages and is created automatically the first time an organization uses check-in, from a built-in template:

Stage	Id	Meaning
Waiting	0	In the queue. What the screen lists.
Assigned	1	Seated or handed off. Terminal — the task is done.

Each stage carries a notification template pair: task-assignment / task-assignment-sms when a task enters stage 0, and task-status-update / task-status-update-sms when it advances. Those are the generic workflow notifications; the guest-facing "your table is ready" message is separate and described below.

A task is the queue entry

The task's payload holds what the queue needs:

Payload field	Source
`customer { name, email, phone }`	The booking's customer, or what was typed for a walk-in
`reservationId`	The booking, if there is one
`businessLocationId`	Where the party is waiting
`partySize`	From the booking or the walk-in sheet
`preferences`, `notes`	Seating intent, requests
`servicePointId`, `assignedAt`	Written by Assign
`source`, `arrivalTime`	`walk-in` or the booking's source; when they arrived

The server enriches every queue row with waitedMs, isOverdue (the task's dueDate SLA has passed), queuePosition (1-based, by creation time) and a displayName that falls back from name to email to phone to "Guest".

Getting into the queue

Walk-in — POST /checkin/walk-in. Needs at least one of name, email or phone. The server attaches or creates the CRM customer when an email or phone is given, creates a lightweight reservation flagged as a walk-in with status pending so the task has a real owner, then fires the task.

From a booking — POST /checkin/from-reservation/:reservationId, which is what the Reservations screen's Check in button calls. The rules:

The booking must not be cancelled, no_show or already used.
If the booking already has a live task, the second call is refused with 409 "Already in the check-in queue" — a double tap cannot queue a party twice.
The operator's selected location is stamped on the task (and onto the booking if it had none). A task without a location never appears in the location-scoped queue.
The booking is stamped with checkedInAt and checkInTaskId, which is what the Reservations screen reads to show "In check-in queue" instead of the button.

Host actions

Action	Task	Service point	Reservation	Guest notified
Assign	Stage 1, status done, `servicePointId` on payload	`occupied`, with `currentReservationId`, `currentPartySize`, `seatedAt`	`used`, `usedAt`, `servicePointId`	Yes — email and SMS
Notify	Unchanged	Unchanged	Unchanged	Yes — same message re-sent
Left	Cancelled, note "Guest left: reason"	Unchanged	Unchanged	No
No-show	Cancelled, note "No-show"	Unchanged	`no_show`	No
Clear (Spots panel)	—	`dirty` or `available`	—	No

Assign refuses a service point whose status is occupied or reserved, and refuses a task that is already done. It accepts the point's record id or its name; the server writes back by id either way.

POST/checkin/walk-inUSER

POST/checkin/from-reservation/:reservationIdUSER

POST/checkin/:taskId/assignUSER

POST/checkin/:taskId/notifyUSER

POST/checkin/:taskId/leaveUSER

POST/checkin/:taskId/no-showUSER

POST/checkin/service-point/:spId/clearUSER

GET/checkin/queueUSER

GET/checkin/queue/summaryUSER

GET/checkin/queue/historyUSER

GET/checkin/upcomingUSER

GET/checkin/reservations/todayUSER

GET/checkin/service-point/availableUSER

The "table ready" message

Assign and Notify both dispatch reservation-ready and reservation-ready-sms to whatever contact details the task carries — email, phone, or both. A walk-in with no contact details is seated silently; Notify on such a task does nothing and says so. The message context is the reservation record (or a minimal { customer, name: 'walk-in' } stand-in) plus the service point, so the template can name the table.

Templates are edited in Studio Manager. See notifications.

Wait times and SLAs

Upcoming (GET /checkin/upcoming) looks one hour backwards as well as forwards, so a late booking still surfaces.
Position and ETA for a guest are position times the average historical stage-0 wait; once a task leaves stage 0 the answer is "past queue".
Overdue is the task's dueDate. It drives the red state on queue cards and feeds the manager dashboard's breached and upcoming escalations (GET /workflow/escalation/breached, .../upcoming).

The other built-in pipelines

The same setup service creates these on first use, and the Pipelines screen can show any of them:

Workflow	Stages	Used by
`prep-pipeline`	Received → Prepping → Ready → Delivered	POS "Send to prep"
`reservation-checkin-pipeline`	Waiting → Assigned	Check-in
`pickup-pipeline`	Order pickup	Storefront
`service-appointment-pipeline`	Appointments	Reservations
`application-processing-pipeline`, `renewal-pipeline`	Back-office	CRM
`stowbo-custody-pipeline`	Custody hand-offs	Stowbo

A product can point at a different prep workflow through its workflow field. Firing is idempotent: lines that already carry a task id are skipped, and firing a tab whose lines are all fired is refused.

When something goes wrong

Symptom	Cause	Fix
The queue is empty and staff insist people are waiting	The screen is on another location, or the tasks carry no location	Check the location picker. A task without a location never appears in a scoped queue.
Assign failed, or a point will not accept a party	The point is `occupied` or `reserved`, or the task is already done	Clear or free the point first; refresh the queue if the task was handled elsewhere.
A party is in the queue twice	Two entries were created from different screens	Left on the duplicate — it closes the queue entry and leaves the booking alone.
Notify appears to do nothing	The walk-in has no email or phone	Expected. Add contact details when taking the walk-in if you want to text them.
No "table ready" message arrives	Templates missing, or no contact details on the task	Check `reservation-ready` / `reservation-ready-sms` in Studio Manager, then the guest's details.
Everything shows overdue	The workflow's SLA `dueDate` is shorter than your real waits	Adjust the SLA on the workflow rather than ignoring the red.
Waits look wrong on the manager view	It reads historical stage-0 averages	Expected early in a shift; the figure settles as the day fills.
A no-show did not mark the booking	Left was used instead of No-show	Left closes the queue entry only; No-show is what writes the booking.
The seated table never freed	Nobody cleared the point after settling	Clear it from Spots or Floor; seating does not release on payment.

Tabs, floor and reservationsThe Check-in screen, walk-ins and the Spots panel.Locations and service pointsStatuses, and who is allowed to write them.Pipelines and kitchen ticketsWorking tasks on any workflow from the app.