Build rescheduling as a complete change of appointment

Define what happens to the old slot

PostgreSQL transactions can group related database changes so that an incomplete group does not become the committed result. For rescheduling, the business requirement is that an appointment should not lose its old place without securing the intended new outcome. Decide whether a customer can move directly or must request an owner-approved change. Make that distinction visible in the action label.

List what moves with the appointment: service, staff assignment, location, payment reference and customer notes where appropriate. Some choices may need to change at the new time. A longer service cannot simply inherit a shorter vacant slot because the interface shows it as available.

• PostgreSQL: transactions ↗

Check availability at the decision point

Show suitable alternatives, then verify the selected option when the move is finalized. Another person may have taken it since the list loaded. If it is no longer available, explain the result and preserve the existing appointment according to the chosen business rule.

Handle staff and location changes explicitly. If the new time requires a different provider or branch, tell the customer before confirmation. Decide whether those changes require additional approval. A reschedule should not quietly alter the service the person originally agreed to receive.

Coordinate the resulting records

The owner should see one current appointment with a clear change history, not two apparently active bookings. Preserve the previous time for reference without counting it as occupied. Any payment or deposit treatment should follow the business's actual policy rather than being inferred by the builder.

Treat external calendar updates and customer messages as separate steps to verify. If a message fails after the appointment moves, the owner needs a way to see and resolve the communication gap. Do not undo a valid reservation automatically unless that is an explicitly chosen recovery policy.

Test the move and the failed move

Use a sample appointment to move to an available time, then attempt a move to a slot that becomes unavailable. Refresh both customer and owner views after each attempt. Confirm that the current reservation, capacity and history agree, including after a repeated confirmation click.

Also test a customer who abandons the change halfway through. Their original appointment should follow the documented rule, with no unexplained temporary reservation left behind. A complete rescheduling journey tells both sides where the appointment now stands and what remains to be communicated or approved.