# Notifications

> The notify step: email, SMS, WhatsApp (session vs. template, handled automatically), and help-desk tickets — with DND and suppression enforced on every send.

The **Send a notification** step is how a workflow reaches out — to the customer, to the owner, or to the team. Four channels:

| Channel | How it sends | Needs |
| --- | --- | --- |
| Email | Your wording with `{{variables}}` — to the customer, the owner, or any address | Nothing extra |
| SMS | Texts through an [SMS service](/docs/doors/sms) in the business | A2P-registered SMS service |
| WhatsApp | **Session text** inside Meta's 24-hour window; an **approved template** you pick outside it — the right one chosen automatically | A [WhatsApp service](/docs/doors/whatsapp) |
| Help desk | Opens a [ticket](/docs/helpdesk/overview) with the person as requester and your summary in the body | A help-desk service |

## Suppression is enforced at the send

Every SMS and WhatsApp notification checks [DND](/docs/crm/dnd) before it leaves: if the contact opted out — on that channel or entirely — the send is skipped and the run log says so. Workflow authors don't manage compliance; the platform does.

## Who receives it

Notifications address the person the run is about by default (the caller, the form-filler) — their phone and email arrive as run context. Owner/team alerts just use a fixed address instead. The two combine naturally: "email the customer a confirmation *and* SMS the on-call tech" is two notify steps.

> **TICKETS ARE A NOTIFICATION:** The most under-used channel. "AI couldn't answer", "voicemail left", "refund requested" — anything a human must own becomes a ticket with the transcript, so it can't be lost in someone's inbox.