First Class Modules

Notifications

Provides recipient-scoped alerts with unread filtering, detail, dismissal, source-record context, relations, activity, and source favorites.

Runtime key
module.notifications
Experience
Personal alerts
Security
Server-enforced

Use Notifications for personal awareness of events, assignments, changes, and workflow outcomes that do not require the richer ownership lifecycle of Universal Inbox.

Note

The bundled renderer key is module.notifications. First-class means BuildWithHQ supplies a native, typed, secured runtime experience inside normal app provisioning and the signed-in user's existing permissions.

What it does

Provides recipient-scoped alerts with unread filtering, detail, dismissal, source-record context, relations, activity, and source favorites.

Key capabilities

  • Search current-recipient notifications and filter unread items.
  • Open bounded detail and mark or dismiss notification state.
  • Show a permitted source title, location, relations, and activity.
  • Favorite an authorized source record directly from the notification.

Common uses

  • Assignment, mention, publication, and status-change alerts.
  • Workflow completion, failure, or approval attention.
  • Personal reminders that link back to the canonical source record.

How it connects

Notifications point to native source records across modules. Use Universal Inbox for shared triage, ownership, SLA, and AI action preparation; use Notifications for recipient-scoped awareness.

Where applicable, its records use the universal RecordId conventions so they can participate in secured relationships, activity history, favorites, dynamic fields, notifications, Inbox attention, and global search without copying the source record.

Security and data boundary

Only rows for the current recipient and app/account are returned. Linked source metadata appears only after its normal DataRole and location checks; the browser cannot submit recipient or permission authority.

  • The authenticated service derives the SaaS app, tenant account, user, DataRole, and location scope; browser identifiers are never authorization proof.
  • The page editor composes React components with validated data bindings. Those bindings call typed runtime APIs, whose application services execute reviewed stored procedures.
  • List, search, detail, relation, activity, favorite, and write operations reapply their required server-side permissions.

Add it to an app

  1. Open the SaaS app in the Developer Console and identify the user journey and page where this module belongs.
  2. Add the validated module.notifications module block through the supported page/template authoring flow.
  3. Configure the module with the page editor's React components and validated data bindings; the bindings call authenticated platform APIs backed by reviewed stored procedures.
  4. Place the page in the correct user-type menus and assign existing DataRole, record, field, and location permissions.
  5. Test list, detail, search, empty, denied, stale-update, and cross-location behavior before publishing an exact version.
Tip

Notify only when the recipient can act or benefit. High-volume events should roll up into an Inbox queue, digest, or dashboard rather than producing alert fatigue.

Important

A renderer being bundled in the tenant application does not make its data visible in every app. The server returns only components and records authorized for the current app and signed-in user; unavailable or unauthorized blocks fail closed.