> ## Documentation Index
> Fetch the complete documentation index at: https://notifizz.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Broadcasts — One Mailing to a Segment
> Launch a one-off mailing to a CRM segment: audience resolution, frozen snapshot, pacing, scheduling, stopping, and what the report tells you afterwards.
# Broadcasts
Most of Notifizz reacts to something a user did. A **broadcast** doesn't wait: it is a mailing you launch — now or at a chosen time — to a segment that lives in your CRM. Same campaign object, same review flow, same channels; only the trigger differs.
**Closed beta.** Broadcasts are enabled per organisation and are off by default. If you don't see the option in your dashboard, ask your Notifizz contact to switch it on.
## TL;DR
* A broadcast is a campaign whose trigger is a **launch**, not an event. It needs a trigger mode (manual or scheduled), a CRM segment, and at least one email before it can go to Review.
* **The segment is read live from your CRM at launch** — Attio today. Nothing is copied into Notifizz beforehand.
* **The audience is frozen at launch.** Late CRM edits don't change a mailing already under way.
* **A broadcast launches once.** To send again, duplicate the campaign.
* **Large or first-time sends are paced automatically** to protect a young sending domain.
* **Stopping is honest about what already left**: a scheduled broadcast is cancelled cleanly, an in-flight one is stopped best-effort and reported as sent.
## What makes a campaign a broadcast
An [event-driven campaign](/docs/concepts/campaigns) fires once per matching event, for the recipients its orchestrator resolves. A broadcast fires **once, for a list**.
| | Event-driven campaign | Broadcast |
| ----------- | ------------------------------------------- | -------------------------------------------------- |
| Trigger | An event your code emits | A launch — manual or scheduled |
| Audience | Resolved per event by the orchestrator | A CRM segment, resolved once at launch |
| Runs | Every time the event matches | Exactly once |
| Typical use | Order shipped, password reset, trial ending | Product announcement, newsletter, migration notice |
Everything else is shared: the statuses, the review flow, the channels, the sandbox rules. A broadcast that is still in `Review` reaches your sandbox testers, exactly like any other campaign — see [send scope](/docs/concepts/campaigns#send-scope).
## Before it can reach Review
A broadcast is refused promotion until three things exist:
1. **A trigger mode** — manual, or scheduled for a given moment.
2. **A CRM segment** — the audience source.
3. **At least one email** — a broadcast with nothing to send is not a broadcast.
A fourth condition is checked immediately before *every* send, review simulations included: the campaign's orchestrator must be **up to date** with the current configuration. This one is worth understanding rather than working around. The orchestrator is what maps each CRM record onto the template's merge fields; without a current one, the personalisation resolves to nothing and the mail goes out carrying only its static copy — to the whole segment, silently. A refused send is recoverable. That one is not.
## The audience
### Read live, stored nowhere
At launch, Notifizz asks your CRM for the segment's current members and maps each one to a recipient. **Nothing is persisted before that moment** — there is no audience list sitting in Notifizz waiting for you to press send, and no sync keeping a copy warm. This is the same principle as [enrichers](/docs/why/enrichers), applied to segments.
Two normalisation rules apply as the list is read:
* **`id` and `email` are reserved.** A CRM attribute of the same name cannot overwrite them — an attribute never gets to decide who a recipient is.
* **Rows without a usable email are dropped**, then duplicates are collapsed on the normalised address. A contact listed twice in a segment is one recipient; the first occurrence wins, and the order you'd see in your CRM is preserved.
Every other attribute on the record travels with the recipient as a personalisation variable, ready for the template's merge fields.
Consent is *not* applied here. Unsubscribed and suppressed recipients are dropped later, as the mailing fans out, and re-checked again for each individual message — so someone who unsubscribes between the launch and their own message still doesn't receive it.
### When the segment is too big to read whole
Every CRM connector has a ceiling on how much of a segment it will return in one read. When a segment exceeds it, Notifizz **refuses the launch** rather than mailing the part it managed to fetch:
> This segment exceeds the connector's read limit: the broadcast would only reach some of its members. Relaunch confirming the partial send if that is what you want.
You can override it — relaunch and confirm the partial send explicitly. Three properties of that override are deliberate: it is carried by the launch itself, so it can never be switched on once and forgotten as a setting; it is logged; and it is frozen onto the broadcast, so the report still says so long after the CRM has forgotten the question.
The alternative — sending to the first N members and saying nothing — is the failure this guard exists to prevent. A truncated blast looks exactly like a successful one from the outside.
### Frozen at launch
Once resolved, the list is **frozen**. Contacts added to the segment while the mailing is under way are not picked up, and contacts removed are still mailed unless they unsubscribed. The frozen snapshot is what makes the run reproducible and the report meaningful — a moving audience would make "how many did we reach?" unanswerable.
## Pacing
A large mailing is not dispatched as fast as the infrastructure allows. Notifizz picks one of two regimes at launch and **freezes it** onto the broadcast, so a resumed run keeps the spacing it started with:
| Regime | Behaviour | When |
| ---------- | ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| Full speed | Batches of 1,000, back to back | The default — an organisation with sending history on an established domain |
| Gentle | Batches of 500, one minute apart (≈500 mails/minute) | A sending domain verified less than 14 days ago, or the organisation's first mailing above 5,000 recipients |
The gentle regime is not a throttle you're being punished with: a young domain that suddenly emits 100,000 messages looks exactly like a compromised one to receiving providers. Ramping keeps a 100k send under roughly three and a half hours while the domain builds its reputation. See [domain reputation](/docs/operations/gmail-postmaster) for what receiving providers watch.
## States
A launched broadcast reports the state of its mailing, not the campaign's status:
```mermaid theme={null}
stateDiagram-v2
[*] --> Scheduled
Scheduled --> Sending
Sending --> Sent
Scheduled --> [*]: stopped — back to Review
Sending --> Sent: stopped — partially sent
Sent --> [*]
```
| State | Meaning |
| ----------- | --------------------------------------------------------------------- |
| `Scheduled` | Launch is armed for a future moment. Nothing has left. |
| `Sending` | The mailing is under way. |
| `Sent` | Every batch has been handed off. The counts are frozen at this point. |
A manual launch goes straight to `Sending`.
**A broadcast launches once.** There is no relaunch, no second run, no "send again to the people who didn't open". Attempting it is refused: *This broadcast has already been launched — duplicate the campaign to prepare a new mailing.* Duplicating is the supported path, and it gives you a fresh campaign with its own review, its own audience resolution and its own report.
## Stopping
Stopping means two different things depending on when you press it, and Notifizz reports which one happened rather than assuming.
**A scheduled broadcast** has not sent anything yet. Stopping cancels it cleanly and the campaign returns to `Review` — re-arm it, or walk it back to editing through the normal transitions.
**A broadcast already sending** cannot be un-sent. Stopping is an emergency brake, best-effort by nature: batches still queued are pulled, mail already in flight is gone. The campaign **stays `Live`**, and the mailing reads `Sent` — because it partly was. What you get is a report of what actually went out, not a pretence that nothing did.
The distinction matters at the moment you need it most. A stop that claimed "cancelled" while thirty thousand messages were already delivered would be worse than no stop at all.
## The reputation brake
Broadcasts are suspended automatically when an organisation's spam-complaint rate reaches a critical level, and resume on their own once it drops. A launch attempted during that window is refused with an explicit reason rather than queued.
Transactional traffic is never affected — it runs on a separate path, and a password reset is not the thing to hold back because a newsletter went badly.
## Testing before you commit
From `Review`, you can run the broadcast against a **sample of the real segment**, through the real pipeline: real audience resolution, real personalisation, real rendering. Delivery safety is the standard review rule — real mail reaches only your organisation's verified sandbox addresses, everything else lands in your outbox view.
Each simulation is a fresh run: click twice and you get two entries in the review feed. That's deliberate — a test you can't repeat isn't much of a test.
## The report
Once a mailing completes, its counts are frozen: how many recipients the snapshot held, how many messages were handed off, and what came back. A broadcast launched on a truncated segment says so in its report, permanently.
Delivery detail — opens, clicks, bounces, complaints — lives where every other campaign's does, in [delivery history and stats](/docs/operations/delivery-history-and-stats).
## FAQ
Attio today. The audience layer is connector-based, so others follow the same shape as they ship — see [integrations](/docs/sdks/how-to/integrations) for the connectors currently available and how a source is wired to an environment.
Not as a relaunch — a broadcast runs once. Duplicate the campaign and target a segment that expresses the follow-up ("didn't open the announcement"), built on your CRM side where the engagement data lives. The duplicate gets its own review, its own audience resolution and its own report, which is what keeps the two mailings independently measurable.
No. Consent is checked as the mailing fans out and again for each individual message, not at the moment the audience was resolved. The frozen snapshot fixes *who was in the segment*, never *who is still allowed to be mailed*.
The launch fails and says so; nothing partial goes out. A scheduled broadcast that fails this way ends in a terminal failed state rather than sitting in `Sending` forever — the failure is visible and actionable instead of silent.
Because the campaign's configuration changed after the orchestrator was generated, and the orchestrator is what binds CRM attributes to the template's merge fields. Sending anyway would deliver the static copy with every variable unresolved, to the entire segment. Regenerate the orchestrator from the campaign, then relaunch.
Yes, and it behaves like any other campaign there: the mailing runs, but delivery reaches only your sandbox testers. It is the honest way to rehearse a large send — the pacing, the personalisation and the report are all real. See [send scope](/docs/concepts/campaigns#send-scope).
## See also
Statuses, review flow and send scope — shared with broadcasts.
Connecting the CRM your segments come from.
What receiving providers watch, and why pacing exists.
Opens, clicks, bounces — after the mailing.