Antylogic
DemoApp login

399 operational guides

Docs sections
DocsReservations
Device

Edit reservation

Update an existing reservation from a Harbor Soho service occurrence, including guest details, party size, timing, duration and table handling. When saved, the same editor can also create or update the linked customer record.

In this article

This guide is for front-of-house operators and reservation managers who correct an existing booking while planning or running a service.

The reservation occurrence remains the operational starting point. Antylogic loads the occurrence, reservations, table assignments, customers, layout and optimisation state before the operator opens the editor.

Before you start

  • The operator is signed in with an organisation and location selected, for example Harbor Demo Group and Harbor Soho.
  • The service occurrence is open from the reservations calendar or the occurrence deep link, and the reservation belongs to that occurrence. In the GB demo, Liam Scott is the editable reservation in `RESERVATION_OCCURRENCE_ID`.
  • The role has `reservation:view` to load the occurrence, reservations and assignments, and `reservation:manage` to open and save the editor.
  • Use `customer:view` to prefill linked customer details, and `customer:manage` if the save creates or updates the customer.
  • A layout with loaded tables is available if the operator needs to select tables. Normal editing is not available for a waiting-list-only occurrence.

Instructions

  1. 1.

    Open the service occurrence

    Open the reservation calendar and enter the Harbor Soho service occurrence, or use `/:orgId/:locationId/reservations/:occurrenceId?returnRoute=LocationReservationsCalendar&returnMode=week`. The page should show the reservation list or timeline after loading occurrence, reservation, assignment, customer and layout data.

  2. 2.

    Open the reservation editor

    Choose the reservation row, the Edit action, or the reservation on the timeline when editing is enabled. The editor opens with the linked customer name and phone, party size, start time, duration, current status and table mode already populated.

  3. 3.

    Correct guest and booking details

    Update the customer name, customer phone, number of people, time and duration as needed. Keep status changes out of this flow; the implemented editor shows status as read-only and separate actions handle cancellation, uncancellation and status updates.

  4. 4.

    Choose the table mode

    Use the table mode to decide how selected tables should be treated. Indifferent clears table preferences, Preferred sends selected tables as preferred, Required sends them as restricted, and Assign sends them as direct assignments. If the mode is not indifferent, select at least one valid table from the loaded layout.

  5. 5.

    Save the edit

    Choose Save. Antylogic sends the reservation update, then updates the linked customer with the edited name and phone. If the reservation had no customer, it creates the customer first and uses the new customer id in the reservation update. After success, the occurrence data refreshes and the editor closes.

  6. 6.

    Handle manual confirmation or errors

    If automatic optimisation rejects the new seating distribution, the editor offers Save and switch to manual. Confirm only when the operator accepts manual handling for that occurrence. For other save errors, the editor stays open and shows the resolved API error message.

Validations and limits

  • Missing `orgId`, `locationId` or `occurrenceId` leaves the screen in a not-found state.
  • Without reservation view access, the occurrence detail shows a no-permission state for reservations.
  • The Edit action and mutable save require `reservation:manage`.
  • Customer name and customer phone are required after trimming whitespace.
  • Party size must be greater than zero; the UI limits the picker to 1 through 99.
  • Duration is aligned to the configured slot interval and is limited up to 480 minutes.
  • If table mode is not indifferent, at least one selected table must still exist in the loaded layout.
  • When `table_ids` are sent, the backend replaces the complete table assignment set for the reservation.
  • A waitlist reservation ignores normal time, duration and table assignment changes, and waiting-list-only occurrences disable normal editing from the main surfaces.
  • The backend validates that any `customer_id` exists and is global or belongs to the active location.
  • Manual confirmation appears for optimisation error 6200 and retries the reservation save with `confirm_manual_mode: true`.
  • Reservation and customer persistence are separate calls. If the customer update fails after the reservation update, no rollback of the reservation save was demonstrated.

Expected result

The occurrence returns with refreshed reservation data. Guest details, party size, timing, duration and table handling reflect the saved edit, the linked customer is created or updated when applicable, and the occurrence optimisation state may be refreshed or moved to manual mode after confirmation.

Related articles