Change Reservation Status

In this article

Before you start

• The operator is signed in to Harbor Demo Group with Harbor Soho selected.
• The operator has location-level `reservation:manage`; view-only access can inspect the occurrence but cannot change status.
• The reservation already exists in the selected service occurrence and belongs to Harbor Soho.
• Recovery is only offered when the occurrence is not completed and the cancelled reservation can return to booked.
• Waitlist promotion requires a waiting-list occurrence and at least one compatible slot returned by waitlist analysis.

Instructions

1. 1.

   Open the service occurrence

   From the reservations calendar, open the Harbor Soho occurrence that contains the reservation. Wait until the reservation list, customer context, table assignments and timeline have loaded before using any status action.

2. 2.

   Confirm management access

   Check that row actions and editing controls are available. If actions are hidden or disabled, the current user can view the occurrence but cannot update reservation status.

3. 3.

   Review the current status

   Open the reservation editor when you need to check customer, party size, time, duration and tables. Treat the Status field as informational; the implemented editor does not provide a general status dropdown.

4. 4.

   Cancel an active booking

   Use the dedicated cancellation action for an active reservation such as Liam Scott. After confirmation, Antylogic marks the reservation as cancelled, records the cancellation time, clears physical table assignments and refreshes the occurrence.

5. 5.

   Recover a cancelled booking

   When recovery is available, use the dedicated recovery action to move the cancelled reservation back to booked. Do not use this in completed occurrences; if manual confirmation appears, continue only when switching the occurrence to manual handling is acceptable.

6. 6.

   Promote a waitlisted reservation

   Open the waiting-list occurrence, choose Waitlist, select Sara Molina, pick one compatible calculated slot and confirm. The system moves the reservation from waitlist to booked using that slot's start time and duration.

7. 7.

   Verify the refreshed result

   After any status change, recheck the reservation list, timeline and table assignment state. The refreshed occurrence is the source of truth because the update invalidates optimisation and waitlist-analysis cache.

Validations and limits

• `reservation:manage` is required for status-changing actions and for `PUT /api/app/{orgId}/{locationId}/reservations/{reservationId}`.
• The reservation id must exist, belong to the active Harbor Soho location and be loaded inside the selected occurrence.
• Supported data states are `waitlist`, `hold`, `booked`, `seated`, `noshow` and `cancelled`, but this UI only exposes cancellation, recovery and waitlist promotion as operator status workflows.
• The editor's Status field is read-only; do not document a general status selector for this screen.
• Cancelling sets `cancelled_at`, clears reservation table assignments and may trigger post-cancel optimisation work.
• Recovering clears `cancelled_at`; it is disabled for completed occurrences and can require manual-mode confirmation in automatic open mode.
• Waitlist promotion requires `start_at` from a compatible waitlist-analysis slot and cannot continue when no compatible slot is returned.
• Waitlist and cancelled reservations do not keep physical table assignments after the update.
• The occurrence version, optimisation cache and waitlist-analysis cache are invalidated after the change.

Expected result

The reservation remains auditable in Harbor Soho with its status updated. Table assignments, cancellation timestamp, occurrence refresh and optimisation state stay consistent with the selected cancellation, recovery or waitlist-promotion outcome.