​

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.

​

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 fires once per matching event, for the recipients its orchestrator resolves. A broadcast fires once, for a list. 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.

​

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, 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: 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 for what receiving providers watch.

​

States

A launched broadcast reports the state of its mailing, not the campaign’s status: A manual launch goes straight to Sending.

​

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.

​

FAQ

​

See also