> ## Documentation Index
> Fetch the complete documentation index at: https://notifizz.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Product announcement
> One mailing, the whole customer base, a fixed hour — and a wrong price spotted twelve minutes in. The timeline, including the launch that gets refused on purpose.
## TL;DR
**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.
Ardoise, a time-tracking product for design studios, is opening a new paid tier. One email, to every workspace owner, Thursday at 9 a.m. Nothing in the product triggers it — a human decides, and that is precisely why it needs brakes.
| Need | How you do it in Notifizz |
| ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| Mail a **list** instead of reacting to an event | A campaign in the **Marketing** category: its audience is a CRM segment, read at launch |
| See the real email before committing | **Simulate** from Review — a small sample of the real segment, through the real pipeline, delivered only to your sandbox addresses |
| Send at a chosen moment | Trigger mode **scheduled**. Nothing is read, resolved or frozen until the clock strikes |
| Not scorch a young sending domain | Automatic pacing — a domain verified ten days ago earns the gentle regime, 500 at a time, a minute apart |
| Undo what can be undone, and say so | **Stop**, plus a report that states what actually left |
## The situation
Ardoise's Studio plan goes on sale Thursday. Marketing writes one email; it goes to workspace owners, about forty thousand people, in a single wave. There is no sequence, no objective, no per-person clock — the other cases in this section are built on all three, and this one is built on none of them.
What it has instead is a moment. Everything about a broadcast is organised around the fact that pressing the button is irreversible, and that it happens once.
## Why the obvious approach fails
The tempting shortcut is to reuse the machinery Ardoise already has: emit an event per customer from a script, and let an existing campaign react to it.
It falls apart on four things a mailing needs and a loop of events does not give you:
* **A list.** An event-driven campaign resolves its recipients **per event**, through its orchestrator and the [enrichers](/docs/why/enrichers) it calls. There is no audience to hand it.
* **A rate.** Forty thousand events fired as fast as a script can fire them is the single fastest way to make a young sending domain look compromised.
* **A record** of who was in the wave, fixed at the moment it went out.
* **A way to stop** — one gesture, not forty thousand.
A broadcast is the same campaign object in a different category: **Marketing**, which swaps the event trigger for a launch. See [broadcasts](/docs/concepts/broadcasts) for the mechanics; what follows is the week.
## Tuesday — build it, then rehearse it against real data
The campaign is created in the **Marketing** category. That choice is what turns it into a broadcast: the audience becomes a CRM segment picked on the campaign, instead of the recipients an event resolves. It also settles the compliance side — `Marketing` is promotional mail, so the message carries a one-click unsubscribe and honours [notification preferences](/docs/concepts/notification-preferences).
Three things must exist before the campaign can reach Review:
1. **A trigger mode** — send now, or schedule for a given moment.
2. **A segment** — the audience source, read from Ardoise's CRM.
3. **At least one email**.
A fourth condition is checked as well, and it is the one worth understanding: the campaign's orchestrator must be **up to date**. The orchestrator is what maps each CRM record onto the email's merge fields. Generated while the copy is still moving, it goes stale, and a stale one resolves nothing — the mail would go out carrying only its static text, to the whole segment, in silence. Review stays locked until it is regenerated.
Then the rehearsal. From Review, **Simulate** pulls a handful of real contacts out of the configured segment — five today — and pushes them through the real pipeline: real audience resolution, real personalisation, real rendering. Delivery safety is the ordinary review rule: real mail reaches only your organisation's verified sandbox addresses, and everything else lands in your outbox view.
Each simulation is a **fresh run**. Click twice and you get two entries in the review feed — deliberate, because a test you cannot repeat is not much of a test. Ardoise runs it three times on Tuesday, the last one after fixing the footer.
Review also tells you whether the *real* send would work at all. If the organisation's email setup is incomplete — no verified sending domain, no sender — the simulation still runs so you can iterate on the content, but Review says out loud that Live would fail. Finding that out on Tuesday costs nothing.
## Wednesday, 10 a.m. — the launch that gets refused
Ardoise's first instinct is to mail everyone: they point the campaign at **All people**, the whole CRM workspace, and press Send while somebody is watching.
It is refused:
> 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.
Nothing left. No mail, no partial wave.
This refusal is the feature. Every CRM connector has a ceiling on how much of a segment it will return in one read, and above that ceiling the honest options are two: refuse, or mail the fraction that came back. The second one is worse than it sounds, because **a truncated blast looks exactly like a successful one from the outside** — the campaign says Sent, the report shows a healthy count, the open rate is fine, and the members who were never in the read simply never hear about the new plan. Nobody discovers that this week. Somebody discovers it in a support ticket in March.
A refused launch is recorded as a **failed send carrying its reason**, and a failed send is not relaunchable in place: an error can strike after part of the fan-out has already left, and Notifizz will not risk doubling those messages. The way forward is to duplicate the campaign — the same gesture as for a mailing that completed.
Ardoise does not need the override anyway. The announcement was always for workspace owners, not for every person ever imported into the CRM: **Workspace owners — active** holds 38,400 records, comfortably under the ceiling. They duplicate the campaign, point it at that segment, walk it back through Review, and re-simulate.
### When the partial send is what you want
It sometimes is — a first wave, a controlled test on a segment you know is capped. Confirm the partial send explicitly on the launch, and it goes out. Three properties of that confirmation are deliberate:
* **It travels with the launch**, never as a setting — so it cannot be switched on once and quietly forgotten.
* **It is logged.**
* **It is frozen onto the mailing.** The report says the audience was truncated, permanently, long after the CRM has forgotten the question.
## Wednesday, 4 p.m. — schedule it
The trigger mode goes to **scheduled**, Thursday 09:00. The button in the Review header reads **Schedule**, with the date in its tooltip, and it arms in two clicks — the second one within five seconds, or it disarms itself.
For a broadcast, **leaving Review is sending**. There is no separate publish step: the campaign is promoted and the mailing armed by the same gesture, which is why the button confirms itself before it fires.
The campaign badge now reads **Scheduled**. This is the part people misread: nothing has been read, resolved or reserved. There is no audience list sitting in Notifizz overnight waiting for 9 a.m. A contact added to the segment on Wednesday evening will be in the mailing; one removed at 08:55 will not.
## Thursday, 09:00 — it goes out, gently
At the scheduled moment the segment is read from the CRM and mapped to recipients. Two normalisation rules apply as the list comes in: `id` and `email` are reserved, so a CRM attribute of those names can never decide who a recipient is; rows without a usable email are dropped, then duplicates collapse on the normalised address. Every other attribute on the record travels with the recipient as a personalisation variable.
38,400 records in, 38,207 recipients out. That list is then **frozen** — the snapshot is what makes the run reproducible and the report answerable.
Ardoise's sending domain was verified nine days ago, so the mailing takes the **gentle** regime: batches of 500, one minute apart. Seventy-seven batches, a little over an hour and a quarter end to end. It is not a punishment — a young domain that suddenly emits forty thousand messages looks exactly like a compromised one to receiving providers. See [domain reputation](/docs/operations/gmail-postmaster).
The badge reads **Sending**, with live progress. Consent is applied here rather than at resolution: unsubscribed and suppressed recipients are dropped as the mailing fans out, and re-checked again for each individual message — so somebody who unsubscribes at 09:30 does not receive the batch that had their name in it.
## Thursday, 09:12 — Stop
Someone in the team reads their own copy and sees it: the Studio plan is announced at **24 € per seat**. It is 34 €.
The stop dialog does not pretend:
> Sending is in progress: emails already sent cannot be recalled. The rest of the queue will be cancelled and the broadcast closed.
They confirm. Batches still queued are pulled. The batch that was running at the moment of the click runs to the end. Everything already handed to the email provider is gone — no platform can reach into an inbox.
What happens next is the part worth reading twice:
| What you might expect | What Notifizz does |
| ------------------------------ | ------------------------------------------------------------------------------ |
| The campaign reverts to Review | It **stays Live** — a mailing that partly went out is not an unpublished draft |
| The mailing reads Cancelled | It reads **Sent**, because it partly was |
| The report shows zeros | The report shows the **real counts**, frozen at the stop |
The last row is the one that earns the feature. A broadcast cut after six thousand messages that reported *0 accepted, 0 failed* would contradict six thousand inboxes and every delivery notification still arriving. So the stop freezes what actually went — and because the running batch is still finishing, the numbers settle over the following moments rather than snapping to a final value. A stop is a snapshot, not a balance.
Ardoise's report, once it stabilises:
| Report | Count |
| -------------------------- | ------ |
| Recipients in the snapshot | 38,207 |
| Accepted | 6,318 |
| Failed | 11 |
| Never entered the mailing | 31,878 |
Six thousand people have the wrong price. Thirty-one thousand have nothing. Both of those are true, both are on screen, and the decision about what to do next is made on real numbers twelve minutes after the mistake instead of on a guess.
Pressed twenty minutes earlier — while the broadcast was still **Scheduled** — Stop would have been a clean cancellation: nothing had left, and the campaign would have dropped back to Review to be corrected and re-armed. Same button, two different meanings, and Notifizz reports which one happened rather than assuming.
## Thursday, 09:40 — the correction
There is no relaunch. **A broadcast launches once**, and attempting a second run is refused: *This broadcast has already been launched — duplicate the campaign to prepare a new mailing.* Duplicating is the supported path, and it gives the correction its own review, its own audience resolution and its own report — which is what keeps the two mailings independently measurable afterwards.
So Ardoise sends two things:
* **A correction** to the people who received the wrong price. Who those are is answerable — [delivery history](/docs/operations/delivery-history-and-stats) lists them, message by message. Turning that into a segment is work on the CRM side; Notifizz holds no list of your contacts to filter.
* **The announcement**, correctly priced, to everyone else. A second duplicate, a different segment.
Neither is automatic, and that is the honest cost of the incident. It is a smaller cost than the alternative, which was to keep sending.
## What Ardoise set up
* A **CRM connection** on the production environment, with a read-scoped API key — see [integrations](/docs/sdks/how-to/integrations).
* One **segment** in that CRM, maintained by whoever owns the CRM.
* A **verified sending domain**, which is also what decides the pacing regime.
* One campaign in the **Marketing** category, with one email.
No event to emit, no enricher to write, no code at all. Notifizz stores none of the contacts: the segment is read at launch and the snapshot lives only as long as the mailing.
## Troubleshooting
The launch conditions are checked when the clock strikes, not when you schedule — the segment is not read before that moment, so a segment that grew past the connector's read limit overnight is discovered at fire time. The send is recorded as failed with its exact reason and nothing partial goes out. For a first whole-base mailing, launching manually at a moment you are watching is worth the small loss of convenience.
Four conditions, and the last one is the one people miss: a trigger mode, a segment, at least one email — and an orchestrator that is up to date with the current configuration. Editing the copy or changing the segment after the orchestrator was generated makes it stale. Regenerate it from the campaign; the panel says so explicitly once you look for it.
That combination points at a configuration change made between the two. The same freshness barrier guards the simulation and the real send, so a stale orchestrator cannot slip past either — but a segment swapped after a successful rehearsal changes which columns exist, and a rehearsal proves nothing about a segment you no longer use. Re-simulate after every change to the segment or the copy.
Most often the segment is bound to a non-production environment. A broadcast launched from there reaches no real recipient — it would run, report Sent, and deliver only to your sandbox addresses. Notifizz blocks it rather than let it look successful, and it blocks the same way while the segment's environment is still being verified. Pick a segment bound to production.
Consent is the usual answer. The snapshot fixes who was in the segment; it never decides who is still allowed to be mailed. Unsubscribed and suppressed people are dropped as the mailing fans out, and the check runs again for each individual message. The report separates what was accepted, what failed and what was never attempted, so the three are not confused with one another.
Expected. The audience is frozen at launch: late arrivals are not picked up, and contacts removed mid-flight are still mailed unless they unsubscribed. A moving audience would make *how many did we reach?* unanswerable, which would in turn make the report worthless.
That is the reputation brake: marketing sends are suspended automatically while an organisation's spam-complaint rate sits at a critical level, and resume on their own once it drops. Transactional mail is never affected. The Reputation page shows the rate and the verdict, provider by provider — see [deliverability](/docs/operations/deliverability).
## See also
The mechanics behind this timeline: audience resolution, freezing, pacing, stopping, the report.
Statuses, categories and send scope — shared with every other campaign.
Who received what, message by message — the answer to the correction question.
The opposite shape: no list, one entry per person, and a sequence that stops on the act.