Dispatch Notification

🔀

Sub-flow: Dispatch Notification SUC-NOT-01

This page is a sub-flow invoked from another use case — when finished, control returns to the caller.

⚠ Inferred Draft — No screen specification exists for this sub-use case.
SUC-NOT-01 is a fully automated background process — no user input is required. The steps below are derived from the SUC detail YAML for prototype reference.

Process Overview — System executes automatically on invocation

Receive notification request from the originating module

The request specifies the notification type, the intended recipient(s), and the information needed to compose the message. Routing rules per notification type: SS-NOT.01.
Confirm this notification has not already been sent

Duplicate prevention policy: SS-NOT.07. AF 2A: Notification already sent → skip
Identify available delivery channels and prepare message content

In-app: always included. Push: only if mobile app installed and notifications enabled. Email: only if recipient has a registered email address. Message matched to recipient's preferred language. Language fallback: SS-NOT.06. AF 3A: Message format unavailable → record failure
Send notification through each available channel and record result

In-app: new notification entry appears in recipient's inbox (UC-NOT.03). Email: sent via external email service (ACT-07). Push: sent via push notification service. Each channel result recorded separately (UC-NOT.04). Re-send and failure handling: SS-NOT.05.

Success Outcome

Recipient has a new notification in their inbox (UC-NOT.03)
Each channel has sent or will be retried automatically
Delivery record exists per channel (UC-NOT.04)
Request marked processed — duplicate sending prevented

Failure Outcome (AF 3A)

No notification sent — message format unavailable
Operations team alerted for resolution

✓ Finish & Return to caller ✕ Cancel sub-flow

Screen Flow (SUC-NOT-01):

→ Process complete → Return to caller → Cancel → Caller (sub_cancelled=1)

Spec notes

Key	Value
Identity	SUC-NOT-01 · Dispatch Notification · dispatch-notification
Purpose	Route and deliver a notification triggered by an external module event (LMS, CCM, FRM, BIL) via Kafka. Channel routing: in-app (always), push (if user has FCM token / mobile app installed), email (if user has a registered email address). Records delivery attempt and outcome per channel.
ReturnUrl context	Current value: `/review-and-approve-course/` Fallback rule: if returnUrl is empty, Finish → `/`; Cancel → `/?sub_cancelled=1` Propagation: returnUrl carried via query string through all SUC screens
Sub-flow context	SUC ID: SUC-NOT-01 Invoked by: UC-LMS.07 (Enroll in Course), UC-CCM.05 (Submit Course for Publish), UC-CCM.06 (Review and Approve Course), UC-BIL.01 (Purchase Course)
Preconditions	System has received a notification request with recognized type and identified recipient; recipient has an active account
Additional requirements	AR1: Delivery channel assignment and routing rules — SS-NOT.01 AR2: Duplicate notification prevention policy — SS-NOT.07 AR3: Re-sending schedule for failed delivery attempts — SS-NOT.05 AR4: Notification message format selection and language fallback — SS-NOT.06