MCMMCM DocsEngineering (Internal)
User StoriesMCM-13 — Notification System
v1.2 is unreleased — see v1.1 for the current stable release.

MCM-13 — Notification System

Overview, personas, and architecture for the MCM platform notification system.

MCM-13 — Notification System

The MCM platform generates events continuously — budget thresholds breached, deployments finishing, policy violations detected, approval requests pending. The Notification System surfaces these events to the right users at the right time through three delivery channels: real-time WebSocket in-app notifications, browser-level Web Push for out-of-focus alerts, and Email for persistent, actionable records.

Each user story below is a self-contained page with its own acceptance criteria, technical design, and UI changes. This page holds only what's shared across all of them: personas, the shared delivery-channel architecture, notification taxonomy, and cross-cutting NFRs.


Personas

PersonaRolePrimary concern
Enterprise AdminManages accounts, users, and policies within a tenantOperational health of the entire enterprise
FinOps UserMonitors cost, budgets, and forecastsCost anomalies, budget breaches
SecOps UserManages governance policies and security scansPolicy violations, critical CVEs
Orchestration UserDeploys and manages workspaces and stacksDeployment outcomes, approval gates
MSP AdminManages multiple enterprise tenantsTenant-level health events

User Stories

StorySummary
MCM-14 — Real-Time In-App Notification BellA notification bell in the top nav shows unread alerts in real time.
MCM-15 — WebSocket Real-Time DeliveryThe transport that pushes events to the bell within 2 seconds.
MCM-16 — Web Push NotificationBrowser-level push alerts even when the MCM tab isn't focused.
MCM-17 — Email NotificationPersistent, actionable email record for critical events.
MCM-18 — Notification PreferencesPer-category, per-channel opt-in/opt-out control.
MCM-19 — MSP-Level NotificationsA separate feed for MSP Admins covering tenant-level events.
MCM-45 — Module Usage Plan Threshold and Expiry NotificationsWarn when a module's own usage plan nears or hits its limit, independent of the enterprise's overall subscription.
MCM-46 — FinOps New Recommendation NotificationNotify when a new cost-saving recommendation is generated, with a "new" indicator that outlives the notification itself.

System Context — Delivery Channel Summary

Channel Characteristics

ChannelLatencyRequires loginPersistedUser opt-out
WebSocket (In-App)< 2 sYesYes (server-side history)Per category
Web Push2–10 sNo (browser running)No (fire-and-forget)Per category + browser
Email< 60 sNoYes (email thread)Per category + unsubscribe link

Notification Categories

CategoryExamplesDefault severity
Budget & CostBudget threshold breached (50 %, 80 %, 100 %), cost anomaly detected, FinOps job failureHigh
RecommendationsNew FinOps cost-saving recommendation generated (see MCM-46)Medium
DiscoveryAccount sync completed, account sync failed at account level, job status/progress, new resource type discoveredMedium / High (account-level failure)
GovernancePolicy violation detected, compliance score change ≥ 10 %, compliance score below 90 % on a scan runHigh
SecOpsCritical CVE found, new security finding, scan failed, scan completedHigh / Medium
OrchestrationWorkspace plan succeeded/failed, provision (apply) succeeded/failed, deprovision (destroy) succeeded/failed, approval request received, approval approved/rejectedHigh / Medium
Module Usage PlansA module's own usage plan (Discovery, FinOps, SecOps, Governance, or Orchestration) reaches 90 % (warning) or 100 % (expired) — see MCM-45Medium / High
BillingInvoice generated, payment failed, subscription expiry warningHigh
User ManagementNew user added, user activated, user deactivated, user role changed, password changedLow
SystemPlatform maintenance window, service degradation, scheduled job failureHigh / Low

Enterprise-account-level activation/deactivation (as distinct from an individual user's) is a tenant-level event surfaced to MSP Admins — see MCM-19 — MSP-Level Notifications, not this table.

Notification Severity Levels

LevelMeaningBadge colour
CriticalImmediate action required — data loss, security breach, payment failureRed
HighPrompt attention needed — budget exceeded, deployment failed, policy violationOrange
MediumAwareness required — sync completed with warnings, score changeYellow
LowInformational — user added, scan completed successfullyGrey

Cross-Cutting Non-Functional Requirements

These apply across every delivery channel; channel-specific NFRs are called out on that channel's own story page.

IDRequirement
NFR-01No notification must be delivered to a user who does not belong to the tenant that owns the triggering resource (strict tenant isolation).
NFR-02All notification payloads in transit must be encrypted (TLS 1.2+).
NFR-03Notification history is retained for 7 days; anything older is not returned by the bell drawer or its API, regardless of channel.

Out of Scope

  • SMS / WhatsApp delivery channels (future consideration).
  • In-app notification sounds.
  • Notification grouping / threading (batching multiple events into a single notification entry).
  • Third-party webhook delivery (e.g. Slack, PagerDuty) — tracked separately.

On this page