Staff Notification
What It Is
A staff notification connects an application event to the people whose work it concerns. It includes the declared event contract, the producer's submission and the recipient items created by processing. Staff experience it through their inbox; producers experience it as transactional publication; administrators inspect its request and delivery history. These are facets of one broad announcement model.
The declaration separates stable product wording and validation from a particular event. The submission supplies the happening and audience. The recipient item provides localized content, a destination and personal read or archive state. Keeping those distinctions inside one concept prevents a route, queue record or classification from becoming a separate product noun.
What It Is Not
A notice does not grant the recipient responsibility or permission. Following its destination still uses the application's ordinary authorization. Staff notification also differs from association e-mail: the product declares notification wording and selects staff audiences, while association communications use workflow purposes and association or caller content.
How It Is Used
Application teams register event declarations during deployment. Producers publish within business transactions, and Platform resolves current audiences after commit. Rendering creates recipient items and available channel deliveries. Staff read and organize their own items; administrators inspect workspace outcomes and authorized HQ operators investigate customer history with grants.
Repeated events can collapse, while withdrawal and expiry stop stale pending work. Already-delivered console items remain readable when they become inapplicable. Stored preferences are preparation rather than current channel behavior. Retirement cancellation and external provider proof have explicit limits in the findings.
Its Facets
Rendered item. Rendered content connects a recipient to the event and its work.
Personal organization. Read and archive marks organize the recipient's own inbox.
Delivery progress. Channel results determine progress independently of read state.
Combined contributions. Matching events contribute to one item without losing request references.
Selection explanation. Recipient selection and channel reasons make delivery understandable.
Channel attempt history. Attempts and feedback preserve each channel's delivery history.
Future recipient configuration. Stored choices prepare future controls without affecting current routing.
History window. Monthly partitions bound the retained notification history.
Application identity. Stable application keys identify declared event types across releases.
Preference category. Categories group future preference choices while retaining declaration identity.
Importance. Severity communicates how prominent an item should appear.
Configuration boundary. Preference mode constrains permitted future channel choices.
Supported delivery routes. Supported and default routes bound the delivery options.
Permitted audiences. Accepted audience forms constrain how a producer selects people.
Declared request fields. Closed data contracts and examples validate requests and templates.
Localized content. Localized templates supply product-authored wording for each channel.
Navigation and actions. Destination metadata connects notices to console work.
Repetition and lifetime. Collapse, expiry and replacement bound useful event presentation.
Registration lifecycle. Retirement preserves declaration identity and targets pending cancellation.
Stored workspace customization. Stored workspace overrides await a future release plan.
Operational channel mapping. System declarations map directly to Rhythm operational channel keys.
Event identity. Producer event keys identify retried publication work.
Recipient selection. Audience entries select current holders and eligible staff during processing.
Event context. Event data and subject records support rendering and collapse.
Delivery interval. Not-before and expiry instants govern pending work.
Replacement and withdrawal. Replacement keys and cancellation keep announcements aligned with business state.
Processing result. Processing outcomes explain acceptance and recipient-less requests.
Rejected outsiders. Isolation refusals identify candidates excluded by customer boundaries.
Closure. Settlement closes changes after expiry and outstanding work.
Transactional queue entry. Transactional queue insertion follows the producer's commit or rollback.
HQ selection. System audiences select HQ channels rather than customer staff.
How It Relates
Association communication shares durable queued publication but serves a different recipient and content outcome. Published association templates belong to that e-mail workflow. Responsibility assignments and customer provisioning are source events owned elsewhere; this module describes their notification contract without taking ownership of those business records.
What It Could Become
The product should complete the shared header bell and delivery explanations before relying on them as finished entry points. Later channel choices, quiet hours and digests require approved plans and runtime activation. Andrew should resolve the reserved system workspace and partial retirement recovery before design assumes those boundaries are settled.