Communication — Case thường gặp

"Notification mới tạo job nhưng không gửi ra"

Thường do Notification Settings ở bước Scheduler. Kiểm tra theo thứ tự:

1. Loại notification đã seed vào NotificationOption cho BU chưa? (loại mới phải seed trước khi gửi được.)
2. BU có subscriber/recipient không? Không có → handler skip gracefully.
3. Generator có handler cho loại mới chưa? Feature mới có thể chưa wire route.

Ví dụ thực tế: Bật loại notification mới cho BU, job tạo ra nhưng khách không nhận. → Khoanh vùng nghẽn ở Scheduler/Generator. → Loại mới chưa seed vào NotificationOption cho BU → seed trước rồi mới gửi được.

Thêm placeholder vào template

Template dùng {{...}}. Ví dụ booking-notification-checkout-instruction thêm placeholder hướng dẫn checkout. Quy trình:

1. Thêm placeholder vào template.
2. Đảm bảo handler ở Generator cung cấp giá trị cho placeholder đó khi render.
3. Placeholder thiếu dữ liệu → render rỗng (kiểm tra fallback).

Ví dụ thực: {{INCIDENT_DETAILS_LINK}} trỏ tới trang /attendance/incident-management (chưa có deep-link tới một incident cụ thể — đổi sang deep-link khi route tồn tại).

Tắt/giảm một loại thông báo

Một số tình huống cần suppress (nén) notification:

Case	Cách
Không gửi notification cho booking đang pending	Mute ở điều kiện pending
Tắt notification booking theo cấu hình subscription	Setting ở subscription

Mute/suppress là notification-only: không đổi state booking/enrollment/invoice (xem nguyên tắc "alert mute is notification-only" bên Subscription).

Cấu hình recipient mặc định cho site

• Seed email người nhận mặc định cho site.
• Tùy chọn copy email cho site contact.

"Khách nhận email trùng" (phía gửi)

Khác với trùng ở Platform (tạo job trùng), ở đây là trùng lúc gửi. Phòng bằng send claim:

Created/RetryReady -> Sending  (cập nhật có điều kiện)

Nếu thấy vẫn trùng: kiểm tra (1) OutgoingMessage có đúng "một dòng/người nhận/kênh" không (RecipientKeyHash ổn định?), (2) send claim có thật sự điều kiện theo Status không, (3) AttemptNo có bị thêm ngoài ý muốn không.

Ví dụ thực tế: Một phụ huynh nhận 2 email xác nhận booking giống hệt nhau. → Mỗi người/kênh chỉ gửi một lần. → Send claim chuyển Created → Sending có điều kiện theo Status → worker thứ hai không claim lại được.

Campaign gửi tới nhiều người: payload lớn

Dùng MessagingJob + Blob. Lưu ý:

• Nội dung lớn để ở Blob (messaging-job container), SQL chỉ giữ điều phối + tên blob.
• Retry tái dùng blob payload tương thích; payload lệch → dừng + báo xung đột (không ghi đè).

Báo cáo định kỳ (report subscription) cutover an toàn

Report subscription là một đường mỏng có:

• Shadow mode + allowlist + one-owner guard để scheduler cũ và mới không bao giờ cùng gửi một kỳ báo cáo.
• Cutover từng bước, rollback được. Chi tiết: Report Subscription.

"Việc bị skip/deactivate — tại sao không gửi?"

Khi automation bị skip/deactivate, không có delivery. Lý do nằm ở AutomationScheduler.DispatchResultJson (SkippedReasonCode/ConflictReasonCode/Summary) và các màn hình support — không phải ở pipeline gửi.

Ví dụ thực tế: Support được hỏi vì sao reminder của một lịch không gửi. → Tìm đúng nơi giải thích thay vì lục pipeline gửi. → Đọc DispatchResultJson thấy SkippedReasonCode → automation bị skip có chủ đích, không phải lỗi gửi.