Notification Type

What It Is

This record is superseded. The notification declaration is a facet of Staff Notification, and the permanent record remains available for historical references. The active staff model combines declarations, transactional requests, recipient items and delivery history.

Applications need a shared description of the events they can announce before they submit live requests. A notification type supplies that description. It separates the stable identity of an event from any particular occurrence or recipient. The registration catalog therefore lets Platform validate a producer's contract and lets HQ inspect the notification vocabulary across applications.

The declaration also places boundaries around data and rendering. A producer cannot treat a notification request as arbitrary prose addressed to arbitrary people. The registered type describes which audience forms, fields and delivery routes are available. Its wording belongs to the product rather than to an association editing its member e-mail.

What It Is Not

A notification type describes an event class, not a particular event or inbox item. Audience membership belongs to a submission. Association-authored e-mail belongs to the communication template model, where the workflow purpose and published wording serve a different recipient outcome.

How It Is Used

Application teams submit manifests during deployment. Platform checks schema shape, examples, channel wording and destination metadata before storing changes. HQ can read the shared catalog through controlled access. Definitions retain their permanent identity across releases, so retirement preserves historical references. Cancellation of pending work follows registration separately and can fail in an individual workspace.

Its Facets

Application identity. A permanent three-segment key identifies the notification type and the application that declares it. Separate application namespaces and preserve references across releases.

Preference category. Nine recognized categories organize notification types, including assignments, approvals, jobs, billing, security and system. Group personal choices without changing the category of an established key.

Importance. Info, important and critical express the notice's severity. Present urgency and support future quiet-hour decisions.

Configuration boundary. Fully configurable, channel-configurable and mandatory modes constrain future choices. Preserve required defaults, including e-mail when that channel is supported.

Supported delivery routes. A declaration identifies supported and default channels and always includes console support. Limit routing and explain channels that are unavailable or unsupported.

Permitted audiences. Types cover individual users, user groups, responsibilities, roles and permissions; system declarations can address HQ. Validate the producer's method of selecting recipients.

Declared request fields. A closed data schema accompanies one to ten representative examples. Check submitted data and exercise wording during registration.

Localized content. Each channel has language-specific templates, with English as the baseline. Render content for the recipient's locale.

Navigation and actions. Destination metadata describes the console route and additional actions. Connect the notice to the work that prompted it.

Repetition and lifetime. Collapse, expiry and replacement settings control how an event stays useful. Reduce bursts and stop stale work.

Registration lifecycle. Declared types are active; omitted types become retired and remain retained. Preserve history while targeting unsettled requests for cancellation.

Stored workspace customization. Settings and published wording overrides exist in persistence but are not applied by the current pipeline. Provide configuration primitives for a later planned release.

Operational channel mapping. Code maps system definitions to Rhythm's Slack channel keys. Route HQ alerts without customer configuration.

How It Relates

A submission names one registered, active type. Recipient notices use its templates, category and severity. Future personal and workspace settings are constrained by its preference mode, but their stored existence does not mean the current pipeline applies them.

What It Could Become

The product should plan workspace wording and preference controls before enabling the stored configuration. It should also resolve the retirement recovery gap and preserve a clear distinction between approved declaration policy and additional implementation validation. Action execution from external channels requires a separate permission and interaction design.