The Notifications Bell and the Morning Digest
How the bell counts up, what triggers a notification, and why the digest exists to roll twelve pings about one deal into one readable summary.
The notifications system is the part of the platform that pings users when something they care about happens. New offer in a deal room. Asset assigned to your testing queue. Settlement awaiting your review. Auction you’re watching just hit reserve. Twelve of those in two hours, all about the same deal, will train users to ignore the bell. The system is built to prevent that.
The bell
Top-bar bell shows an unread count. Click opens the notifications center: a chronological feed with grouping (multiple events on the same entity collapse into one summary). Mark-as-read per item or bulk. The bell count updates in real time via Supabase Realtime — no refresh.
What fires a notification
Event-driven triggers on every state change that matters: deal-room messages, offer changes, asset stage advances, SLA approaching, watchlist alerts, settlement actions, dispute filings, escrow transitions, auction events. Each event type has a default delivery channel (in-app, email, both, neither) and a default urgency.
The morning digest
For users who don’t want twelve emails a day, the digest is the answer. A cron runs every morning, gathers the previous day’s notifications per user, groups them by entity and type, and sends one email summary. Twelve notifications about the same deal become "Deal #1234: 3 messages, 1 counter-offer, 1 acceptance — open deal room." Manageable.
Per-event preferences
Users pick their delivery channel per event type from /settings/notifications. The platform-default is "in-app for everything, email for high-urgency only, digest for the rest." Users with preferences for full email firehose, or no email, or per-event tuning, can configure each separately.