# 6. Notification Settings

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*

---

## 6. Notification Settings

### 6.1 Configure Default Notification Channels
**What it does:** Sets the default notification channels (push, email, SMS) and the per-notification-type channel defaults: which channels each kind of notification uses by default, so users receive the right notifications through the right channels without configuring everything themselves. Users can adjust their own preferences within the configured defaults.

**Sub-features:**
- Channel set: push, email, SMS (enable/disable channels platform-wide)
- Per-notification-type channel defaults (e.g., security alerts via push + email, receipts via email)
- User preference within defaults: users can mute or add channels per type, within the configured set
- Channel capability checks: a channel is used only where the user has it enabled (e.g., SMS only where a phone is verified)
- Default behavior for new users (the starting preference set)
- Consistent application across all notification types
- Audit logging of channel configuration changes

**Super Administrator User Journey:**
1. The team defines the channel policy: security alerts go via push + email, billing receipts via email, and course reminders via push. Super Admin configures these per-type defaults.
2. Confirms the channel set: push and email are enabled platform-wide; SMS is enabled for the high-priority types where a verified phone exists.
3. Sets the new-user default preference: all default channels on, so a new user is notified appropriately from day one.
4. Saves; the per-type channel defaults apply to all users' starting preferences.
5. A user mutes push for course reminders (prefers email); their preference is within the configured set and is respected, while the security-alert channels (which the policy keeps) still reach them.
6. For a user without a verified phone, SMS is not used (the capability check); their notifications go via the available channels.
7. Reviews the channel configuration: the per-type defaults, the enabled channels, and the new-user default are as intended.
8. The channel configuration change is audit-logged with the per-type defaults and the timestamp.

**Rules & Edge Cases:**
- A channel is used only where it is enabled platform-wide and the user has the capability (e.g., a verified phone for SMS).
- User preferences operate within the configured defaults: a user can mute or add channels per type, but policy-critical channels (e.g., security alerts) are kept per the configuration.
- The new-user default ensures a fresh account is notified appropriately without manual setup.
- The per-type defaults are consistent across the platform; a notification type always uses its configured channels.
- A channel failure (e.g., an email bounce) is handled per the delivery rules (retry, fallback where configured).
- Channel configuration changes are audit-logged with the acting admin and timestamp.

### 6.2 Configure Alert Types and Thresholds
**What it does:** Defines the alert types the platform raises and the thresholds that trigger them — the conditions under which an alert is generated (e.g., a security threshold, a usage threshold, a system threshold) and who is alerted. The Super Administrator configures the alert catalog and thresholds so the right signals are raised at the right level, without noise.

**Sub-features:**
- Alert type catalog: the alert types (security, usage, system, business) with their definitions
- Threshold configuration per alert type (the condition that triggers it)
- Alert recipients: who receives each alert type (Super Admin, specific roles)
- Severity levels: the alert's severity and its handling expectation
- Threshold tuning: adjusting thresholds to balance sensitivity and noise
- Alert delivery via the configured channels
- Audit logging of alert configuration changes

**Super Administrator User Journey:**
1. The team wants a security alert when a single account has more than 5 failed logins in 10 minutes. Super Admin opens the alert configuration and sets that threshold for the failed-login alert type.
2. Configures the recipient (Super Admin) and the severity (high), and the delivery channels (push + email per the channel defaults).
3. For a usage alert (a user approaching the AI-interaction cap), sets the threshold at 80% of the cap and the recipient (the user, as a heads-up) at a lower severity.
4. For a system alert (an error-rate threshold), sets the condition and the recipient (Super Admin) at high severity.
5. Saves; the alerts are live: when a condition is met, the alert is raised to the configured recipients via the configured channels.
6. After a period, reviews the alert volume: the failed-login alert is firing too often (noise). Super Admin tunes the threshold (5 → 8 in 10 minutes) to reduce false positives while keeping real signals.
7. Reviews the alert history: each alert shows the type, the threshold crossed, the value, the recipients, and the time — confirming the alerts match the configured conditions.
8. The alert configuration change is audit-logged with the types, thresholds, and recipients, and the timestamp.

**Rules & Edge Cases:**
- An alert fires only when its configured threshold is met; the threshold is the single source of the trigger condition.
- Recipients and severity are configured per type; an alert reaches the right people at the right urgency.
- Threshold tuning is expected: the volume is reviewed and thresholds adjusted to balance sensitivity and noise.
- Alert delivery uses the configured channels; a channel failure is handled per the delivery rules.
- The alert history records the threshold crossed and the value, so each alert is explainable.
- Alert configuration changes are audit-logged with the acting admin and timestamp.