Skip to content

IE.5: Booking Emails and Notifications

Summary

Booking actions trigger email and in-app notifications for clients and counselors. Public or authenticated booking creation can immediately confirm a booking or create a pending request. Confirmation, cancellation, and reschedule events reuse templated email delivery and in-app notification delivery.

Role

  • Primary: Guest, Client, Counselor
  • Secondary: System, Resend

Entry Point

  • Public booking: /book/:slug
  • Embedded booking: /embed/book/:slug
  • Client bookings: /my-bookings
  • Counselor booking management: /booking-settings
  • API examples: booking create, confirm, cancel, reschedule, approve reschedule, reject reschedule

Preconditions

  • Booking widget and session type exist.
  • Requested slot is available.
  • Email service and notification templates are optional but required for actual email/in-app delivery.

Steps

  1. Guest or client books a session from a counselor booking page.
  2. Backend validates availability, creates the booking, and sets status from the widget confirmation mode.
  3. Backend starts post-booking work asynchronously.
  4. If instant-confirmed, backend creates a linked meeting and sends booking_confirmed to the client plus booking_request_new to the counselor.
  5. If request-mode, backend sends booking_received to the client and booking_request_new to the counselor.
  6. Backend creates in-app notifications for authenticated recipients using the same event context.
  7. Counselor can confirm a pending booking; backend creates a meeting and sends booking_confirmed.
  8. Counselor or client can cancel eligible bookings; backend cancels linked meetings where present and sends booking_cancelled to the non-actor.
  9. Client can request a reschedule; backend validates the new time and sends booking_reschedule_requested.
  10. Counselor approves or rejects the request; backend updates the booking/linked meeting and sends booking_rescheduled or booking_reschedule_rejected.

Diagram

Edge Cases

  • Slot conflict: Booking creation returns slot_taken when the database exclusion constraint detects overlap.
  • Email failure: Booking actions still succeed; email failures are logged.
  • Actor suppression: Later booking notifications skip notifying the user who performed the action.
  • Guest booking: Guest email receives email when available; in-app notification requires a ClientUserID.
  • Linked meeting failure: Meeting creation failures are logged and do not roll back the booking.
  • Linked meeting compensation: If meeting creation succeeds but booking link fails, backend attempts to cancel the orphaned meeting.
  • Reschedule conflict: Reschedule request and approval both re-check conflicts.
  • Expired reschedule proposal: Approve rejects proposals whose requested start has passed and clears the request.

Current Implementation Notes

  • Backend: backend/internal/services/booking_service.go
  • Frontend: frontend/src/features/booking/components/public-booking-page.tsx, frontend/src/features/booking/components/my-bookings.tsx, frontend/src/features/booking/components/bookings-management.tsx
  • Templates: backend/scripts/seeds/006_seed_booking_email_templates.sql

Screenshot Status

  • Not captured.