Events & exceptions

The package fires an event for every change, so confirmations, calendar sync and dashboards stay out of your scheduling code. All live in RoundlyConsulting\Appointments\Events:

use Illuminate\Support\Facades\Event;
use RoundlyConsulting\Appointments\Enums\Status;
use RoundlyConsulting\Appointments\Events\AppointmentStatusChanged;

Event::listen(function (AppointmentStatusChanged $event): void {
    if ($event->to === Status::Confirmed) {
        foreach ($event->appointment->participants as $participant) {
            // notify $participant->participant that the booking is confirmed
        }
    }
});

Timing notes

• Every package event implements ShouldDispatchAfterCommit: inside a database transaction it fires once that commits, and never for a write that rolls back.
• A booking is written in one transaction, so AppointmentCreated fires after its participants, contacts and approval request are stored — and a refused or failed booking fires nothing.
• A recurring series is one transaction too: its events fire once the whole series commits, and a series that rolls back fires none.
• reschedule() and status transitions save the model, so AppointmentUpdated fires alongside AppointmentRescheduled or AppointmentStatusChanged.
• A status set at creation with withStatus() doesn’t fire AppointmentStatusChanged, and neither does a transition to the current status.

Exceptions

All live in RoundlyConsulting\Appointments\Exceptions and extend AppointmentsException, so one catch covers the package.