Notification categories explained

Last updated: May 19, 2026

Notification categories explained

Wevion has 22 notification types organized in 8 UI categories (apps/backend/src/lib/notification-defaults.ts). Each notification flows through up to 5 channels (in_app, email, push, telegram, slack) with 5 severity levels (info, low, medium, high, critical). Per-role defaults (ROLE_DEFAULTS) map each type × channel × role to enabled/disabled. Users can override per-type via /settings → Notifications.

Who is this for

Anyone setting notification preferences or wondering why a specific alert arrived (or didn't). Reference page for the full notification taxonomy.

The 8 categories

UI groups types into 8 categories for easier preference management:

Category

What it covers

campaigns

Campaign approval / disapproval, ad set status changes

budget

Spend cap warnings, budget depleted

account

Account status changes, token expiring

kpi

KPI threshold alerts, creative fatigue

sync

Sync completed / failed

operations

Bulk launch, report ready, export ready

creative

Creative job (generation), creative fatigue

team

User added, team member removed

system

System notifications, subscription changes

Setting preferences at category-level toggles all types within. Per-type granularity also available.

The 22 notification types

Verified set from notification-defaults.ts:

Account + auth (4)

  • ACCOUNT_STATUS_CHANGE — ad account status changed (disabled, restricted, recovered)

  • TOKEN_EXPIRING — OAuth token about to expire; re-authorize needed

  • PAYMENT_ISSUE — Stripe payment failed or attention required

  • SUBSCRIPTION_CHANGE — plan changed (upgrade, downgrade, trial expiring)

Budget + spend (3)

  • SPEND_CAP_WARNING — daily spend cap approaching threshold

  • BUDGET_DEPLETED — campaign / adset budget exhausted

  • KPI_THRESHOLD_ALERT — custom metric crossed configured threshold

Campaigns + delivery (3)

  • CAMPAIGN_DISAPPROVED — campaign rejected by platform

  • ADSET_DISAPPROVED — ad set rejected

  • DELIVERY_ERROR — ad serving error reported by platform

Sync + operations (5)

  • SYNC_COMPLETED — periodic sync finished successfully

  • SYNC_FAILED — sync errored

  • REPORT_READY — scheduled report generated

  • EXPORT_READY — bulk export ready for download

  • BULK_LAUNCH_COMPLETED — bulk campaign launch finished

Creative + automation (3)

  • CREATIVE_JOB — Creative Hub AI generation completed

  • CREATIVE_FATIGUE — creative fatigue detected (frequency / CTR decay)

  • RULE_EXECUTED — automation rule fired

  • RULE_ACTION_FAILED — rule tried to act but failed

Team + system (4)

  • USER_ADDED — new user added to team

  • TEAM_MEMBER_REMOVED — user removed from team

  • SYSTEM — generic system notification

The 5 channels

Channel

Where it shows

Setup

in_app

Notification center in Wevion UI

Always on

email

Inbox via noreply@wevion.ai

Always on if user.email set

push

Web push (PWA) via VAPID

Browser permission grant required

telegram

Telegram bot DM

Bot link required (see ntf-104)

slack

Slack channel

OAuth install required (admin)

No mobile push — web push only (VAPID, in-browser / PWA).

The 5 severity levels

Severity

Visual

Use

critical

🔴

Account disabled, payment failed, action urgent

high

🔴

Errors that affect delivery

medium

🟡

Warnings, threshold approaches

low

🟢

Routine successes, info

info

ℹ

Notices, completions

Role-Based Defaults

ROLE_DEFAULTS matrix in notification-defaults.ts: for each role × notification type × channel = default enabled/disabled.

Example for super_admin + ACCOUNT_STATUS_CHANGE:

Channel

Default

in_app

✅ on

email

✅ on

push

❌ off

telegram

✅ on

Example for manager (more conservative):

Channel

Default

in_app

✅ on

email

❌ off (for most types)

push

❌ off

telegram

❌ off

User can override defaults via preferences (see team-116 customize notifications).

Preferences precedence

For each notification → channel decision:

  1. Notification policy engine evaluates event

  2. Apply team-scoped override (admin can disable team-wide)

  3. Apply user-scoped override (per-user toggle)

  4. Otherwise: ROLE_DEFAULTS for user's role

  5. Otherwise: notification-type's catalog default

First match wins.

If decision is IGNORE (user opted out): notification dropped, not enqueued.

Slack subset

Slack only fires for 7 default events (conservative — no success noise):

  • account.disconnected

  • account.token_expiring

  • campaign.publish_failed

  • rule.action_failed

  • sync.failed

  • billing.payment_failed

  • billing.subscription_expired

Other notification types do NOT route to Slack by default. Workspace can customize via notification_policy overrides.

Common questions

Why didn't I get a notification?

  • Check preference for that type × channel at /settings → Notifications

  • Check role default (admin defaults narrower than owner)

  • Check team-wide override (admin may have disabled)

  • For Telegram: verify bot link active (see ntf-104)

  • For email: check spam, verify user.email set

Why am I getting notifications for someone else's actions?

Owner fan-out: if you're the team owner, you receive notifications for team members' triggering actions (e.g. their published campaigns). Owner can disable via preferences.

Can I add custom notification types?

No. The 22 types are platform-defined. Custom thresholds (e.g. KPI alerts) are configured via the Rules Engine — see rul-102.

Can I get notifications in real-time?

In-app: live polling (~30s). Push: instant via VAPID. Telegram: instant (SQS worker). Email: near-instant. Slack: instant. Digest (Telegram only): batched at user's preferred hour.

Common mistakes

  • Disabling all email expecting only in_app: some types only deliver via email by default

  • Expecting mobile push: not implemented; only web push (VAPID)

  • Expecting daily email digest: not implemented; only per-event email + Telegram digest

Related