​

Campaigns

A campaign is a dashboard-defined reaction to an event. It owns the orchestrator code that builds recipients, the channel configurations that render messages, and a status that controls when it runs. This page covers the full lifecycle.

​

TL;DR

• Six statuses: Editing, Implementation, Review, Live, Offline, Archived. Five are runnable; Archived is terminal.
• Only Live and Review deliver from a real event. Live reaches real recipients when the event comes from production, and your sandbox testers otherwise; Review only ever reaches sandbox testers, and only outside production.
• A campaign still being authored stays silent. Editing and Implementation never send from an ambient event — rehearse them from the dashboard instead.
• Each save creates a new version; in-flight workflow instances run against the version they started on.
• Three categories: transactional is served first, then product, then marketing. product and marketing are promotional — the recipient can opt out of them.

​

Statuses

Transitions are enforced on the source status: a move the diagram doesn’t draw is refused. Archived is terminal — there is no un-archive. The six statuses: Live → Review is not a demotion by accident: it’s how a scheduled broadcast is stopped — the send is cancelled and the campaign drops back into the approval stage. The Live ↔ Offline cascade is built in — demoting a campaign cascades to dependents (e.g. archiving the upstream event).

​

Runnable filter

Only Live and Review deliver from a real event. That single sentence covers most of what you need, but it is the result of three separate checks rather than one, and knowing which is which saves a long debugging session. 1. Which campaigns even start. When an event arrives, Notifizz matches campaigns on the event name and keeps a runnable subset — Editing, Implementation, Review, Live, Offline. Archived is the only status excluded outright at this point. Then, if the event came from a production environment, Implementation and Review are dropped as well: both are staged for you to verify, so production traffic must never reach them. 2. Whether the run is allowed to continue. The status is checked again at every step of the run, and this list is shorter: only Live and Review may proceed. A run belonging to a campaign sitting in Editing or Implementation is cancelled — so even though such a campaign passes the first filter and creates a run, nothing is ever sent from it. A run that had already started under Live or Review survives a later move to Offline or Archived: pausing closes the door to new events, it does not cut sequences already under way. 3. How far a delivery may go. For a run that reaches this point, the reach depends on the environment the event came from — real recipients only from production, your sandbox testers everywhere else.

​

Send scope

Sandbox testers are the verified test inboxes and opted-in browsers of your own team. The status is also frozen when the run starts. A campaign that goes Live while a delayed step is still sleeping does not turn that in-flight run into a real send — the run finishes with the reach it started on. Only Live accrues statistics. Sends, opens, clicks and objective reaches produced in any other status are test traffic and never enter your numbers.

​

Versioning

Each save publishes a new campaign version. The version number is monotonic per campaign and stamped on the workflow instance at creation time. In-flight instances run against the version they started on, even if a newer version has shipped since — there’s no mid-flight surprise. Practical implications:

• Editing a Live campaign is safe for in-flight messages.
• Rolling back to a previous version means re-publishing the older orchestrator code (the dashboard exposes a “rollback to version N” UI).
• Two campaigns at different versions targeting the same event each create independent workflow instances on the matching version.

​

Campaign categories

Every campaign carries a category. It decides two things: where the message sits in the sending queue, and whether the recipient can opt out of it. Product and Marketing are both promotional mail: the unsubscribe link, the List-Unsubscribe header and the marketing consent check all apply to them. Transactional is the only exempt category — which is exactly why it must be reserved for mail the recipient triggered and expects. A recipient who marks transactional mail as spam is suppressed permanently by the email provider, and that cannot be undone. Choosing Marketing is what turns a campaign into a broadcast: the audience is a CRM segment picked at launch instead of the recipients an event resolves. Broadcasts are enabled per organisation and off by default. A non-transactional campaign can also carry an optional notification sub-category, so a recipient opts out of one kind of mail instead of all of it. The category field is part of the campaign’s dashboard config; legacy campaigns saved without one default to Product.

​

Binding events to campaigns

A campaign listens on one event. Wiring is a dashboard step:

1. Create or pick an event in the events catalogue.
2. Create the campaign with its orchestrator code.
3. Bind the campaign to the event.

To send to two distinct audiences from one product action, model two events (or one event with a property the campaign branches on) — not two campaigns on the same event with different recipient logic in code. The “one event, many campaigns” pattern is for unrelated reactions (e.g. customer email + ops Slack).

​

FAQ

​

See also