In Laravel, how do you notify someone who has no user account, such as a new patient's phone number, and how do notifiable models route each channel?

## Two ways a channel finds its recipient Every notification channel needs an address: an email, a phone number, a Slack channel, a database relationship. Laravel gets it by asking the **notifiable** — the object you called `notify()` on — through `routeNotificationFor($channel)`. That notifiable is either one of your models using the `Notifiable` trait, or an **anonymous notifiable** built on the spot for someone who has no record. At a dental clinic both happen: registered patients get reminders from their profile, while a walk-in who only left a phone number, or a family member named as an emergency contact, gets an **on-demand** notification. ## Routing on models | Channel | Default route from the trait | Override method on the model | |---|---|---| | `mail` | the `email` attribute | `routeNotificationForMail($notification)` — a string, or `[email => name]` | | `database` | the `notifications()` morph relationship | rarely overridden | | `vonage` | none (`null`) | `routeNotificationForVonage($notification)` | | `slack` | none (`null`) | `routeNotificationForSlack($notification)` | | `broadcast` | the private `App.Models.Patient.{id}` channel | `receivesBroadcastNotificationsOn()` | The pattern is `routeNotificationFor` plus the StudlyCase channel name. When a method exists, it wins; otherwise the trait's default applies, and for most channels that default is `null` — nothing to deliver to. Overrides earn their keep when the obvious attribute is wrong: a clinic may send reminders to `contact_email` rather than the login `email`, or format `phone_number` into international form for SMS. ## On-demand notifications 1. Start from the facade: `Notification::route('mail', '[email protected]')`. 2. Add channels: `->route('vonage', '447700900123')`, or build all routes at once with `Notification::routes(['mail' => ..., 'vonage' => ...])`. 3. Send: `->notify(new AppointmentReminder($appointment))`. `route()` returns an `AnonymousNotifiable` that simply stores the routes; its `routeNotificationFor('mail')` returns what you gave it. For mail, an array `['[email protected]' => 'Ana Silva']` supplies a display name. For broadcast, the route is an array of channel objects. Queueing works as usual: if the notification implements `ShouldQueue`, the anonymous notifiable is serialized with the job. ## Writing notifications that serve both - **In `via()`**, check what you have: `$notifiable instanceof AnonymousNotifiable` has no preferences or opt-ins to read. - **In formatters**, avoid `$notifiable->first_name`; the anonymous notifiable has no attributes. Put names into the notification's constructor instead. - **When `toMail()` returns a mailable**, read the address with `$notifiable->routeNotificationFor('mail')`, since there is no `email` property. ## Limits - **No database channel.** Calling `route('database', ...)` throws `InvalidArgumentException` ("The database channel does not support on-demand notifications."), because a stored notification must belong to a model. If `via()` merely lists `'database'`, the sender skips that channel for anonymous notifiables without an error. - **No per-recipient preferences** unless you pass them in. - **Nothing in the bell.** The person has no account, so the in-app history lives nowhere; if you need an audit trail, record the send yourself. ## A worked clinic scenario A receptionist books a first visit for someone who is not yet registered and ticks "remind by SMS and email": 1. The booking stores the appointment with the contact details typed in. 2. The code calls `Notification::route('mail', [$email => $name])->route('vonage', $phone)->notify(new AppointmentReminder($appointment))`. 3. `via()` sees an `AnonymousNotifiable` and returns `['mail', 'vonage']`, never `'database'`. 4. Later, when the patient registers, their `Patient` model takes over: reminders go through `$patient->notify(...)`, `routeNotificationForVonage()` supplies the number, and `'database'` can join `via()` so the bell shows the history from then on. ## Choosing between the two - The person is a record in your system: make the model `Notifiable` and define the route methods once. - The person is a one-off address — a guardian, a referral contact, an external lab: use `Notification::route()`. - You are tempted to create a stub `User` just to call `notify()`: don't; that pollutes the accounts table and every query over it. ## Summary - `Notification::route()`/`routes()` build an `AnonymousNotifiable` for people without accounts. - Models answer `routeNotificationFor{Channel}()`; the trait defaults cover only `mail` and `database`. - The database channel is never available on demand.