> ## Documentation Index
> Fetch the complete documentation index at: https://notifizz.com/llms.txt
> Use this file to discover all available pages before exploring further.
# What Is Notifizz — Product Overview
> What Notifizz solves, the mental model, where each piece lives in the dashboard. Pair this with how-it-works for the technical pipeline.
# Product overview
Notifizz is the **event-driven notification platform for your whole team**. This page covers the mental model — what Notifizz solves, the four main concepts, where each lives in the dashboard. For the wire-level pipeline, read [how Notifizz works](/docs/concepts/how-it-works).
## TL;DR
* **Emit one event** from your backend with `client.track(eventName, properties)`.
* **A campaign** in the dashboard reacts to that event.
* **The orchestrator** (campaign code, AI-generated, editable) builds the recipient list — directly from properties or via enrichers.
* **Channels** deliver the notification (Notification Center widget today, email next).
That's the full surface. No SDK methods to memorise, no recipient lists at the call site, no client-side workflow targeting.
## The four primitives
```mermaid theme={null}
graph LR
Event[Event
track] --> Campaign[Campaign
dashboard]
Campaign --> Orchestrator[Orchestrator
code + enrichers]
Orchestrator --> Channels[Channels
NC widget + email]
```
### 1. Events
What your code emits. A name (`order.shipped`) plus a JSON properties bag. Defined in your code; registered in the dashboard for visibility. See [events concept](/docs/concepts/events).
### 2. Campaigns
What the dashboard configures. Each campaign listens on one event and decides what notification to send, to whom, through which channel. Statuses (`Editing` / `Dev` / `Live` / `Offline` / `Archived`) gate when it runs. See [campaigns concept](/docs/concepts/campaigns).
### 3. Orchestrator
The code inside a campaign that runs server-side per event. AI generates the boilerplate from the campaign description; you can edit it. It builds the recipient list — directly from event properties, via enrichers (live data fetches), or via dynamic recipient sources. See [orchestrator concept](/docs/concepts/orchestrator).
### 4. Channels
How the notification reaches the user. Today: the Notification Center in-app widget (real-time via real-time stream). Coming next: email. The campaign picks the channel; the channel processor renders + dispatches. See [channels concept](/docs/concepts/channels).
## Where each piece lives in the dashboard
| Surface | Dashboard location |
| --------------------------------- | ------------------------------------------------------- |
| Events catalogue | Environment → Events |
| Campaigns | Campaigns (top nav) → list / detail |
| Orchestrator code | Inside the campaign detail, the "Orchestrator" tab |
| Channel configurations | Notifications (top nav) → list / detail |
| Recipients (output) | Inside the workflow instance detail in delivery history |
| Enrichers | Environment → Enrichers |
| Connectors (Segment / Stripe / …) | Sources (top nav) |
| Delivery history | Delivery History (top nav) |
| Activity log (per campaign) | Campaign detail, "Activity" tab |
| Brands | Brand (top nav) |
| Variables | Inline in the campaign editor + organisation settings |
| API keys | Environment settings → API Keys |
## What Notifizz is not
Three things Notifizz deliberately doesn't try to be:
* **Not an analytics tool.** Use Segment/Mixpanel/Amplitude for "what did the user do". Notifizz is "what notification should fire". The two compose well via the [Segment connector](/docs/sdks/how-to/integrations).
* **Not a marketing automation engine in isolation.** The pillar pages (Wave 2.5) make the case directly — Notifizz is event-driven first, marketing-and-product collaborative second. Pure marketing tools like Customer.io / Braze sit on a different point in the design space.
* **Not a transactional email service.** Email is a channel Notifizz dispatches through; it isn't a generic SMTP relay. If you only need transactional email and never any in-app notifications, lighter-weight tools fit better.
## Mental analogies
If you're coming from a familiar tool, here's the rough mapping:
| If you know… | Notifizz event = | Notifizz campaign = | Notifizz orchestrator = |
| ------------------- | -------------------------------- | ------------------------------------------ | --------------------------------------- |
| **Segment + Knock** | Segment `track` event | Knock workflow | Knock workflow steps |
| **Customer.io** | event-triggered campaign trigger | the campaign itself | the campaign's filters/branches |
| **Braze** | custom event | canvas | canvas steps |
| **Stripe + Resend** | Stripe webhook event | a `case event.type === 'invoice.paid'` arm | the resend `send()` call inside the arm |
The Notifizz model is closest to the third row — it expects you to think in events first, then react to them with code. The dashboard layer sits on top to let marketing edit the reactions without redeploying.
## Why this design
The core invariant is **server-side routing**. The SDK never picks a campaign, channel, or recipient list. Pushing those decisions to the dashboard means:
* Marketing edits campaigns without a dev deploy.
* The same product event drives multiple campaigns over time (transactional + marketing), no code changes.
* AI authoring works because the orchestrator has full visibility — the call site doesn't hide intent in code.
* The audit trail is centralised — every campaign change goes through the dashboard's [activity log](/docs/concepts/activity-log).
The pillar pages walk through each of these in offensive voice — see "why marketing autonomy", "why event-driven", "why enrichers", "why AI", "why whole team" (Wave 2.5).
## Next steps
The technical pipeline end to end.
Send your first event in under five minutes.
Naming, properties, idempotency.
Lifecycle, statuses, versioning.