Notifications

Goal

Read and clear in-app notifications about documents, periods, and other events.

Who it is for

Any signed-in staff user. The notifications API is user-scoped (no extra permission key); you only see your own rows.

Preconditions

• Signed in to the staff app.
• Events are produced by domain flows (e.g. document posted, period closed) via the notification dispatcher.

Steps

1. Open Notifications from navigation (route notifications).
2. Review unread items (types such as document posted / period closed appear in product copy).
3. Open a notification to jump to the related work when a link is provided.
4. Mark one as read, or mark all read.

Result

Your inbox reflects recent system events; unread counts clear after read actions.

Realtime and module contract

In-app rows are pushed on the authenticated user.{userId} websocket channel as .notification.created. The stored row remains the source of truth and the client periodically refreshes it after reconnects.

Modules publish through NotificationDispatcher with an event type, recipient, tenant, JSON payload, and optional stable deduplication key. Navigable payloads use this shape:

{
  "title": "Optional display title",
  "message": "Optional safe summary",
  "route": {
    "name": "named-frontend-route",
    "params": {},
    "query": {}
  }
}

Do not include secrets, full provider errors, or sensitive message bodies in notification payloads because they may be delivered to email or WhatsApp when the recipient enables those channels.

Hard stops

Notification id not owned by you → 404. Portal users have a separate portal experience — this page is staff in-app notifications.

Related

• My Work
• Period close