Notification Channels & Rules
A notification is one business event — an order placed, a payment failed, leave approved, stock running low — delivered through one or more channels. All modules send through the same notification centre, so one set of rules decides who hears about what, and where.
Available channels
| Channel | Needs |
|---|---|
| In-app (the bell) | Nothing; always available. |
| Working mail settings. Send a test first. | |
| Real-time broadcast | The WebSocket server (Reverb) running. |
| Web push and mobile push (FCM) | The person must grant permission in the browser or app. |
| SMS | An SMS provider and credit; costs per message. |
| Slack, Telegram, WhatsApp, Discord | The chat channel connected in Intelligence → AI Channels. |
| Webhook | An HTTPS endpoint in another system. |
How a message is decided
- Is the channel configured? An unconfigured channel is skipped silently — not an error.
- Does the policy allow this event on this channel? (Notifications → Policy)
- Has the person opted out in their preferences?
- Is the notification mandatory? Security alerts, payment failures and legal notices ignore opt-outs.
The delivery log records why each message reached, or did not reach, each person.
Automation rules
Rules send reports and alerts on a trigger or a schedule — for example "when a product runs low on stock", "when a contact message arrives" or "every morning at 9:00, yesterday's sales by channel and outlet". Recipients can be all admins, a role, a group, the author's manager or senior management only, and every recipient must hold the permission the report requires.
Good practice
- Start narrow. The most common complaint is too many notifications, not too few.
- Test each channel after connecting it.
- Send team alerts to a chat channel and customer messages by email; do not mix them.
Terakhir diperbarui: 11/7/2026