# 4. Alert Configuration

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

---

## 4. Alert Configuration

### 4.1 Alert Type Definitions
**What it does:** Defines the alert types available on the platform: the Super Administrator creates and manages alert type definitions (name, description, severity level, target audience, data source, and message template), so every automated alert is built from a governed, reusable definition.

**Sub-features:**
- Alert type creation: name, description, and category
- Severity levels: critical, warning, and informational severities
- Target audience: the recipients per alert type (student, parent, teacher, admin)
- Data source: the metric or event that feeds the alert type
- Message template: the alert message template with placeholders
- Enable/disable: alert types toggled on or off
- available on web
- event logging (action performed)
- Audit logging of alert type definitions

**Super Admin User Journey:**
1. Super Admin opens Alert Configuration and creates a new alert type.
2. Defines the name, description, category, severity, target audience, data source, and message template.
3. Saves; the alert type becomes available for threshold and routing configuration.
4. Disables a deprecated alert type; it no longer raises alerts.
5. Reviews the alert type catalog to confirm the definitions.
6. The definition change is audit-logged with the actor and timestamp.

**Rules & Edge Cases:**
- An alert type cannot be deleted while active alerts reference it; it must be disabled first.
- A message template with unresolved placeholders is rejected on save.
- Severity is fixed per alert type; individual alerts inherit the type's severity.
- A disabled alert type raises no alerts but retains its history.
- Definition changes are audit-logged with the actor and timestamp.

### 4.2 Threshold Settings
**What it does:** Configures the thresholds that trigger alerts: the Super Administrator sets the numeric and temporal thresholds per alert type (e.g., score below 40%, no activity for 7 days, engagement drop of 30%), so alerts fire only when the defined conditions are crossed.

**Sub-features:**
- Numeric thresholds: value-based trigger conditions (score, rate, count)
- Temporal thresholds: time-based trigger conditions (days inactive, overdue)
- Per-alert-type thresholds: thresholds set per alert type
- Segment overrides: thresholds overridden per student segment
- Threshold preview: a simulation of which students would trigger
- available on web
- event logging (action performed)
- Audit logging of threshold settings

**Super Admin User Journey:**
1. Super Admin selects an alert type and sets its numeric and/or temporal thresholds.
2. Applies segment overrides where a segment needs different thresholds.
3. Runs the threshold preview to see which students would currently trigger.
4. Saves; the platform evaluates student data against the thresholds.
5. Reviews the preview results to confirm the thresholds are sensible.
6. The threshold change is audit-logged with the actor and timestamp.

**Rules & Edge Cases:**
- A threshold must be a valid value for its data source type; invalid values are rejected.
- A segment override replaces the base threshold for that segment only; other segments keep the base.
- The threshold preview is a point-in-time simulation; it does not raise actual alerts.
- Threshold changes take effect from the next evaluation cycle.
- Threshold changes are audit-logged with the actor and timestamp.

### 4.3 Escalation Rules
**What it does:** Defines the escalation rules for unacknowledged alerts: the Super Administrator configures the escalation path (who is notified next, after what delay, and at what maximum level), so important alerts that go unacknowledged are escalated until they receive attention.

**Sub-features:**
- Escalation path: the sequence of recipients for unacknowledged alerts
- Escalation delay: the time before escalation to the next level
- Maximum escalation level: the highest escalation level reached
- Acknowledgement tracking: alert acknowledgement state per recipient
- Escalation stop: escalation stops on acknowledgement
- available on web
- event logging (action performed)
- Audit logging of escalation rule configuration

**Super Admin User Journey:**
1. Super Admin selects an alert type and configures the escalation path (e.g., teacher → admin → super admin).
2. Sets the escalation delay per level and the maximum escalation level.
3. Saves; the platform monitors unacknowledged alerts.
4. When an alert goes unacknowledged past the delay, it escalates to the next recipient.
5. When a recipient acknowledges the alert, escalation stops.
6. Reviews the escalation history to confirm the path was followed.
7. The escalation configuration is audit-logged with the actor and timestamp.

**Rules & Edge Cases:**
- Escalation applies only to alert types with escalation enabled; informational alerts do not escalate by default.
- An acknowledged alert at any level stops further escalation immediately.
- Reaching the maximum escalation level stops escalation; the alert remains open until acknowledged.
- A recipient who is unavailable (inactive account) is skipped to the next level.
- Escalation configuration changes are audit-logged with the actor and timestamp.

### 4.4 Notification Channel Routing & Quiet Hours
**What it does:** Routes alerts to notification channels and manages quiet hours: the Super Administrator configures which channel (push, email, SMS, in-app) each alert type/severity uses, and the quiet hours windows during which non-critical alerts are deferred, so alerts reach recipients through the right channel at the right time.

**Sub-features:**
- Channel routing: the channel(s) per alert type and severity
- Severity-based routing: critical alerts routed to higher-priority channels
- Quiet hours windows: the quiet hours start and end times
- Quiet hours scope: per recipient timezone or platform-wide
- Deferral behavior: non-critical alerts deferred until quiet hours end
- Critical bypass: critical alerts delivered immediately regardless of quiet hours
- available on web
- event logging (action performed)
- Audit logging of channel routing and quiet hours configuration

**Super Admin User Journey:**
1. Super Admin configures the channel routing per alert type and severity (e.g., critical = push + SMS + email; warning = push + in-app).
2. Sets the quiet hours windows and their scope (per recipient timezone or platform-wide).
3. Saves; the platform routes alerts per the configuration.
4. A non-critical alert raised during quiet hours is deferred until quiet hours end.
5. A critical alert raised during quiet hours is delivered immediately.
6. Reviews the routing and deferral logs to confirm behavior.
7. The routing/quiet hours change is audit-logged with the actor and timestamp.

**Rules & Edge Cases:**
- A critical alert always bypasses quiet hours; it is never deferred.
- A deferred alert is delivered once, at the end of quiet hours, not repeatedly.
- Channel routing is per alert type and severity; an unrouted combination defaults to in-app only.
- Quiet hours scope per recipient timezone uses the recipient's configured timezone.
- Routing and quiet hours changes are audit-logged with the actor and timestamp.