Skip to main content

​
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

  • Five statuses: Editing, Dev, Live, Offline, Archived. The first four are runnable; Archived is terminal.
  • Dev is gated to dev environments — never runs on prod.
  • Each save creates a new version; in-flight workflow instances run against the version they started on.
  • Two categories: transactional campaigns jump the queue ahead of promotional ones.

​
Statuses

The five statuses:
StatusMeaning
EditingCampaign exists but the orchestrator code is unfinished or unreviewed. Dev-side iteration territory.
DevOrchestrator is staged for review on dev. Runs on dev only; explicitly skipped on production environments.
LiveApproved for production. Receives every matching event in every environment.
OfflinePaused. The campaign is not removed; restart by promoting back to Live.
ArchivedTerminal. The campaign no longer creates workflow instances; existing in-flight instances finish.
The Live ↔ Offline cascade is built in — demoting a campaign cascades to dependents (e.g. archiving the upstream event).

​
Runnable filter

When an event arrives, Notifizz looks up campaigns matching the event name and filters to a runnable subset — Editing, Dev, Live, Offline. Archived is the only status that’s hard-excluded at instance creation. A Dev campaign is then explicitly skipped on production environments — orchestrators staged for review can never accidentally fire on prod traffic. Whether Editing and Offline proceed to actual delivery depends on downstream step processing.

​
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. The 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.

​
Transactional vs promotional

Campaigns carry a category :
CategoryExamplesQueue priority
TransactionalPassword reset, order confirmation, invoice paidHigh — popped first from the dispatch stage
PromotionalMarketing, lifecycle, “we miss you”Standard
The split is enforced at the queue layer. If you have many promotional campaigns and a transactional one fires, the transactional message overtakes the queue. The category field is part of the campaign’s dashboard config; legacy campaigns without it default to Promotional (DEFAULT_CAMPAIGN_CATEGORY).

​
Binding events to campaigns

A campaign listens on one event. Wiring is a dashboard step (or via PUT /v1/events/:workflowId/event):
  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

Dev is for orchestrators that are wired but haven’t been reviewed for production. They run on dev environments so you can fire test events and verify the output without polluting prod. Promote to Live once the dev tasks are resolved and the orchestrator is reviewed.
Most common: the prod environment is missing a dependency the dev environment had — usually an enricher URL or a connector source. Compare the dashboard’s enricher / connector sections between dev and prod. Less common: a property your test events sent isn’t actually present in real production traffic.
Yes — the new version applies only to events that arrive after the save. In-flight workflow instances run against the version they started on. The dashboard’s version history shows what’s currently Live and what’s been published.
They keep running until completion. Archived blocks new workflow instances; existing ones finish on the version they started on. If you need to stop in-flight delivery, archive the campaign and then cancel the queue jobs from the dashboard’s job-monitoring view.
Yes. The dashboard’s version history exposes a “republish version N” action — it duplicates version N as a new version (N+M, where M is the next monotonic step) and sets it Live. Rollback by republish, not by editing the version number directly.
Yes. Each match creates its own workflow instance with its own orchestrator. They share nothing beyond the inbound event payload, and they can be in different states (one Live, one Dev) without interfering.
Set category: 'transactional' in the campaign config. The split affects queue priority, not delivery semantics — your campaign code is the same; only the queue popping order changes. The category field is per-campaign and per-version (you can change a campaign’s priority across versions).

​
See also

Events

Event grammar, properties, idempotency.

Recipients

How the orchestrator builds the audience list.

Orchestrator

The campaign code that runs after match.

Activity log

Audit trail of campaign edits and reviews.