La notifications bell et le digest du matin
Comment la cloche compte, ce qui déclenche une notification, et pourquoi le digest transforme douze pings sur un deal en resume lisible.
Le notifications system est la partie de la plateforme qui ping les utilisateurs quand quelque chose qui les concerne arrive. Nouvelle offer dans une deal room. Asset assigné à votre testing queue. Settlement en attente de review. Auction suivie qui vient d’atteindre reserve. Douze notifications de ce type en deux heures, toutes sur le même deal, apprennent aux utilisateurs à ignorer la bell. Le système est conçu pour éviter cela.
La bell
La bell de la top-bar montre un unread count. Le clic ouvre le notifications center : un feed chronologique avec grouping (plusieurs events sur la même entité se replient en un résumé). Mark-as-read par item ou en bulk. Le bell count se met à jour en temps réel via Supabase Realtime — pas de refresh.
Ce qui déclenche une notification
Des triggers event-driven sur chaque changement d’état important : deal-room messages, offer changes, asset stage advances, SLA approaching, watchlist alerts, settlement actions, dispute filings, escrow transitions, auction events. Chaque event type a un default delivery channel (in-app, email, les deux, aucun) et une default urgency.
Le morning digest
Pour les utilisateurs qui ne veulent pas douze e-mails par jour, le digest est la réponse. Un cron tourne chaque matin, rassemble les notifications de la veille par utilisateur, les groupe par entité et type, et envoie un seul email summary. Douze notifications sur le même deal deviennent “Deal #1234: 3 messages, 1 counter-offer, 1 acceptance — open deal room.” Gérable.
Préférences par event
Les utilisateurs choisissent leur delivery channel par event type depuis /settings/notifications. Le platform-default est “in-app pour tout, email pour high-urgency seulement, digest pour le reste.” Les utilisateurs qui veulent un full email firehose, aucun email, ou du tuning par event, peuvent configurer chaque élément séparément.