# Notifications settings tab wiring audit
The Notifications tab is persisted through the company `notifications` settings group. `NotificationService` and `NotificationSettingsHelper` consume the global email/SMS enable flags, support contact, channel availability, and reminder periods.
## Wired
- `enable_email_notifications` and `enable_sms_notifications` control booking confirmation/reminder dispatch.
- `enable_booking_reminders` and `reminder_intervals` are used by reminder period resolution and the scheduled reminder job.
- `channels` is used to filter available notification channels.
- `contact_email`, `support_email`, and `support_phone` are used in notification contact data.
- SMS provider/API fields are read by the SMS gateway integration when configured.
- Booking confirmation, cancellation, payment, and reminder notification classes use `NotificationSettingsHelper` for channel selection.
## Partial or incomplete
- `enable_push_notifications`, `push_notification_key`, and `push_provider` are stored and exposed, but provider delivery requires a configured push adapter and is not uniformly enabled across every notification class.
- Template fields are available to the multilingual/template notification services, but several legacy mailables still use dedicated Blade templates.
- `send_multiple_reminders` is stored, while the job primarily relies on configured periods and duplicate notification records; behavior should be verified per notification type.
- Event flags (`notify_on_booking_created`, `notify_on_booking_confirmed`, `notify_on_booking_cancelled`, `notify_on_payment_received`, `notify_on_refund_processed`) are persisted but are not consistently checked before every event dispatch.
The scheduled `bookings:send-reminders` command and queued job are implemented and run hourly. PHP syntax validation passed for the notification service paths.