Engineering Blog · Post #15

Notification Architecture: Event-Driven Alerts for Rush, Assignment, SLA Breach, and QC — Wired into the App Header Bell

How InsightUW delivers a Cyber submission rush alert to the right underwriter in under 500ms — through an event-driven notification pipeline that routes alerts by severity, role, and team, surfacing them in the topbar bell icon the moment they matter.

The Problem

Notifications in most underwriting platforms are an afterthought — or entirely absent. The underwriter finds out about a new assignment by checking their queue. The manager discovers an SLA breach when the broker calls. The QC analyst does not know there are items waiting until they open the QC screen and refresh.

The common "solutions" make things worse:

Email notifications for everything: The underwriter's inbox is already a submission intake channel. Mixing system notifications with broker emails creates noise and missed alerts.
No priority distinction: A rush submission notification looks identical to a routine assignment. Everything has the same visual weight, so nothing stands out.
No role-based routing: The entire team gets every notification, even when only one person needs to act.
No in-app presence: Users must check email to know something happened in the platform they are already using.

The result is a reactive workflow where people discover things too late, miss urgent items, and rely on tribal knowledge ("Did you see the email about the rush?") instead of system-driven awareness.

The InsightUW Approach

InsightUW implements a full event-driven notification architecture with five layers: event emission, notification rule engine, routing and delivery, in-app bell integration, and notification lifecycle management.

graph TB subgraph Events["Domain Events"] A["Submission Created"] B["Status Transition"] C["Rush Flagged"] D["SLA At Risk"] E["SLA Breached"] F["Assignment Changed"] G["QC Items Pending"] H["Document Uploaded"] I["AI Analysis Complete"] end subgraph Rules["Notification Rule Engine"] J["Event → Rule Matching"] K["Severity Classification"] L["Recipient Resolution"] M["Dedup / Throttle"] end subgraph Delivery["Delivery Channels"] N["In-App Bell<br/>(Primary)"] O["Email<br/>(Configurable)"] P["MS Teams / Slack<br/>(Optional)"] Q["Push Notification<br/>(Mobile)"] end subgraph Bell["Topbar Bell Integration"] R["Unread Badge Count"] S["Notification Dropdown"] T["Click → Navigate"] U["Mark Read / Dismiss"] end A --> J B --> J C --> J D --> J E --> J F --> J G --> J H --> J I --> J J --> K K --> L L --> M M --> N M --> O M --> P M --> Q N --> R R --> S S --> T S --> U

The Notification Model

Every notification in InsightUW is a structured record with rich metadata for routing, display, and lifecycle management:

Notification Severity Levels

InsightUW classifies notifications into four severity levels, each with distinct visual treatment in the bell dropdown:

Notification Rules: Event-to-Notification Mapping

The rule engine maps domain events to notification specifications. Rules are configurable through the Admin UI.

FIFO Notification Routing

Notifications are delivered in strict FIFO order per recipient. The bell dropdown always shows the most recent notification at the top, and unread items are visually distinct.

sequenceDiagram participant Event as Domain Event Bus participant Engine as Notification Rule Engine participant Queue as Notification Queue (Fifo) participant WS as Web Socket Server participant Bell as Topbar Bell (Browser) participant Email as Email Service Event->>Engine: Rush Submission Assigned (SUB-2026-04-1955) Engine->>Engine: Match rule: rule rush assigned Engine->>Engine: Resolve recipients: USR-1047 (UW) + USR-1040 (Manager) Engine->>Engine: Classify severity: High Engine->>Engine: Check throttle: No prior notification — proceed Engine->>Queue: Enqueue notification for USR-1047 Engine->>Queue: Enqueue notification for USR-1040 Queue->>WS: Push to USR-1047 Web Socket Queue->>WS: Push to USR-1040 Web Socket WS->>Bell: SSE/WS: {"type":"notification","severity":"High","count":5} Note over Bell: Badge updates: 4 → 5 (orange dot for High) Queue->>Email: Send email to USR-1047 (High → email enabled) Queue->>Email: Send email to USR-1040 (High → email enabled)

Topbar Bell Integration

The bell icon in the InsightUW header is the primary notification surface. It shows an unread count badge and opens a dropdown with the notification list.

Use Case: Cyber — Rush Submission for DataShield Corp

The Scenario

Aon submits a Cyber Liability application for DataShield Corp, a cloud security company with $800M revenue, requesting $25M Cyber coverage. The broker marks it as RUSH — the current policy expires in 5 days, and the incumbent carrier has non-renewed due to a recent ransomware claim. The submission arrives at 10:14 AM.

What Happens in InsightUW (Timeline)

Time	Event	Notification	Recipient	Severity
10:14:00 AM	Email received, submission created	—	—	—
10:14:01 AM	Rush flag detected in subject line	"Rush Submission Received: DataShield Corp"	CBP Queue (team_cyber)	HIGH
10:14:02 AM	FIFO assignment to James Park (UW)	"Rush Submission Assigned: DataShield Corp"	James Park (UW) + Catherine Walsh (Mgr)	HIGH
10:14:02 AM	Rush SLA applied (12 hours vs 48)	—	—	—
10:14:03 AM	Bell badge updates for James Park	Badge: 4 → 5 (orange dot)	James Park	—
10:14:04 AM	Email notification sent	"RUSH: Cyber submission for DataShield Corp assigned to you"	James Park (email)	HIGH
10:14:30 AM	Extraction complete	"AI Extraction Complete: DataShield Corp"	James Park	NORMAL
10:15:00 AM	QC auto-approved (confidence 0.95)	"QC Approved: DataShield Corp"	James Park	NORMAL
10:15:01 AM	AI analysis auto-triggered (rush config)	—	—	—
10:15:08 AM	AI analysis complete	"AI Analysis Complete: DataShield Corp (8/8 checks passed)"	James Park	NORMAL
10:15:08 AM	Bell badge updates	Badge: 5 → 8	James Park	—
10:15:10 AM	James opens bell, clicks rush notification	Navigates to SUB-2026-04-1955	—	—
2:00 PM	SLA 75% elapsed (9 of 12 hours)	"SLA At Risk: DataShield Corp (3 hours remaining)"	James Park + Catherine Walsh	HIGH
4:30 PM	James issues quote	"Quote Issued: DataShield Corp ($185,000)"	Catherine Walsh (Mgr)	NORMAL
4:30 PM	Broker notified	External email with quote letter	Aon broker	—

Notification Volume Control

Without throttling, the above scenario would generate 15+ notifications. InsightUW's throttle rules keep it to 8 meaningful notifications:

Rush assignment: 1 notification (not repeated)
SLA at-risk: 1 notification (throttled to max 1 per submission per 4 hours)
QC/extraction/analysis: 3 notifications (informational, not throttled because they are distinct events)
Quote issued: 1 notification to manager (not throttled because it is a distinct lifecycle event)

WebSocket Connection for Real-Time Updates

The bell icon maintains a persistent WebSocket connection for instant notification delivery:

Notification Lifecycle

stateDiagram-v2 [*] --> Created: Event triggers rule Created --> Delivered: Pushed via Web Socket + Email Delivered --> Read: User clicks or opens Delivered --> Expired: TTL reached (7 days default) Read --> Dismissed: User dismisses Read --> Acted: User clicks action url Acted --> Archived: Auto-archive after action Dismissed --> Archived: Immediate archive Expired --> Archived: Auto-archive Archived --> [*]

Metrics: Before and After InsightUW Notification Architecture

Metric	Before InsightUW	After InsightUW	Improvement
Time to awareness (new assignment)	30–120 min (check queue manually)	< 1 second (push notification)	99% faster
Rush submission response time	2–4 hours (discovered late)	4–12 minutes (instant alert)	95% faster
SLA breaches per month	12–18 (discovered after breach)	2–4 (at-risk alerts enable intervention)	75% reduction
Notifications missed (email buried)	15–25%	< 2% (in-app bell)	90% reduction
Notification noise (irrelevant alerts)	60% of emails irrelevant	< 5% (role/team routing)	92% reduction
Manager awareness lag	Hours (manual checking)	Real-time (dashboard + bell)	Eliminated
Time from QC approval to UW opening	45–90 min (no notification)	5 min average (instant notification)	94% faster
Mean time to act on notification	N/A (no tracking)	12.8 minutes	Measurable

Key Takeaways

Notifications are a routing problem, not a broadcasting problem. InsightUW routes each notification to the specific people who need to act, based on role, team, and assignment — not to everyone.
Severity levels create visual hierarchy. A pulsing red badge for an SLA breach looks and feels different from a static blue count for a routine assignment. The underwriter's eye is drawn to what matters most.
The topbar bell is the primary notification surface. Users are already in the application. Making them check email for system notifications is a design failure.
Throttling prevents notification fatigue. The rule engine limits repeat notifications per submission, preventing the "boy who cried wolf" effect that causes users to ignore all alerts.
Every notification is actionable. Each notification includes an action url that takes the user directly to the relevant submission or screen. Click the bell, click the notification, and you are there.

Ready to replace email chaos with precision alerts? InsightUW's notification architecture delivers the right alert to the right person at the right time — in the app, in the bell, in real-time.

Schedule a Notification Architecture Review →