# 3. Account Status Management

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

---

## 3. Account Status Management

### 3.1 Activate Accounts
**What it does:** Moves an account into the active state so it can log in and use the platform. Activation applies to new accounts awaiting enablement, previously suspended accounts being restored, and invite-pending accounts being confirmed. It is the inverse of suspension/deactivation and is always a deliberate, audited action with user notification.

**Sub-features:**
- Activate a single account from its record
- Activate previously suspended accounts (restore access, resume subscription per policy)
- Confirm invite-pending accounts as active on first-login completion
- Bulk activation for a selected set
- User notification on activation (for restored accounts)
- Subscription handling on re-activation (resume, prorate per policy)
- Audit logging with actor, reason, and timestamp

**Super Administrator User Journey:**
1. A suspended user's appeal is resolved in their favor. Super Admin opens the account record, reviews the appeal outcome, and selects "Activate".
2. Enters the reason ("Appeal upheld — violation cleared") and confirms.
3. The account is active immediately: the user can log in, and their active-state restrictions are lifted.
4. Per policy, the paused subscription resumes: the next billing cycle is restored, and any proration is applied per the billing rules.
5. The user is notified: "Your account has been re-activated."
6. For a batch — an institute's students were suspended during a data issue and are now cleared — Super Admin selects the set in the directory, chooses "Activate", reviews the preview (count and the reason), and confirms the bulk activation.
7. Reviews the directory filtered by the institute to confirm all accounts are active.
8. Each activation (individual and bulk) is audit-logged with the actor, reason, and timestamp.

**Rules & Edge Cases:**
- Activation of a suspended account is immediate; the user can log in on the next attempt.
- Re-activation resumes subscription handling per policy (resume, prorate); it does not silently restart a lapsed payment method without confirmation.
- Activating a deactivated (permanently closed) account is not available from this flow; that requires the restore path within the retention window (see Authentication & Access / Data Protection).
- Bulk activation requires a confirmed preview of the affected count and a recorded reason.
- The user is notified of re-activation so the change is not silent.
- Every activation is audit-logged with actor, reason, and timestamp.

### 3.2 Suspend or Deactivate Accounts
**What it does:** Controls the two blocking states: suspension (temporary, reversible, data retained — for policy violations, security holds, or administrative pauses) and deactivation (permanent closure, triggering privacy data handling). Both are deliberate, reason-recorded, user-notified actions with immediate effect on access and sessions.

**Sub-features:**
- Suspend: temporary block with a reason; data retained; reversible; active sessions ended; billing paused per policy
- Deactivate: permanent closure; triggers the privacy data-handling flow (deletion/anonymization per retention); downstream effects handled
- Reason presets plus free-text note for both
- User notification with the reason and the appeal/contact path (suspension) or the closure summary (deactivation)
- Bulk suspension/deactivation with a confirmed preview
- Audit logging with actor, reason, and timestamp

**Super Administrator User Journey:**
1. A user is flagged for repeated policy violations. Super Admin opens the record, reviews the violation history, and selects "Suspend".
2. Chooses the reason preset "Policy violation" and adds a note referencing the incidents. Confirms.
3. The account is blocked immediately: the user cannot log in, active sessions end on their next request, and recurring billing is paused per policy.
4. The user is notified with the reason and how to appeal.
5. The user appeals; the appeal is tracked (see Account Requests). If upheld, Super Admin activates the account (see 3.1); if rejected, the suspension stands and the user is informed.
6. For a permanent closure (a user requests account closure), Super Admin selects "Deactivate", reviews the data-handling summary (what will be deleted, what is retained and anonymized for legal reasons, the downstream effects — subscription cancellation, seat release), and confirms.
7. The deactivation executes: personal data is handled per the privacy policy, the subscription is cancelled with refund per policy, and any institute seat is released.
8. Both actions are audit-logged with the actor, reason, and timestamp; the deactivation additionally records the data-handling outcome.

**Rules & Edge Cases:**
- Suspension is immediate and reversible; deactivation is permanent (restore only via the retention-window path).
- Suspension pauses recurring billing per policy; deactivation cancels the subscription with refund handling per policy.
- Both actions end active sessions (on the next request) and notify the user with the reason.
- Deactivation triggers the full privacy data-handling flow; it is not a simple status flip.
- Bulk operations require a confirmed preview of the affected count and a recorded reason.
- Every status change is audit-logged with actor, reason, and timestamp.

### 3.3 Delete Accounts
**What it does:** Provides the final removal of an account record, distinct from deactivation: where deactivation closes the account and handles personal data per privacy policy, deletion removes the account record itself after the retention and legal-hold checks pass. Deletion is the last step in an account's life and is tightly gated.

**Sub-features:**
- Deletion eligibility check: account deactivated, retention window elapsed, no legal hold, no open financial obligations
- Downstream check: no active subscription, no allocated seat, no open support tickets
- Explicit confirmation with the irreversibility warning and the eligibility summary
- Removal of the account record with retention of required audit/financial references (anonymized)
- Audit logging of the deletion with the eligibility summary and the acting admin

**Super Administrator User Journey:**
1. A deactivated account has passed its retention window with no legal hold. It appears in the "eligible for deletion" list.
2. Super Admin opens the account and runs the deletion eligibility check: deactivated (yes), retention elapsed (yes), legal hold (none), open financial obligations (none), active subscription (none), allocated seat (none), open tickets (none).
3. Reviews the eligibility summary — all checks pass — and selects "Delete account".
4. The confirmation shows the irreversibility warning and the summary of what will be removed and what anonymized references remain (audit/financial).
5. Confirms; the account record is removed. Anonymized references remain in the audit and financial records so historical integrity is preserved without identifying the individual.
6. The deletion is audit-logged with the eligibility summary, the acting admin, and the timestamp.
7. For an account that fails a check (an open support ticket), the deletion is blocked with the specific reason; Super Admin resolves the blocker (closes the ticket) and re-runs the check.
8. Reviews the deletion log periodically to confirm deletions are occurring only for eligible accounts.

**Rules & Edge Cases:**
- Deletion is blocked unless all eligibility checks pass; the specific failing check is shown.
- Deletion is irreversible; the confirmation makes this explicit.
- Anonymized references remain in audit and financial records for integrity and compliance; the individual is no longer identifiable from them.
- Deletion is distinct from deactivation: deactivation handles personal data per privacy policy; deletion removes the record after retention.
- Legal holds block deletion regardless of retention; the hold must be released first.
- Every deletion is audit-logged with the full eligibility summary.

### 3.4 Status Change Notifications and Appeals
**What it does:** Ensures status changes are never silent: the user is notified of activation, suspension, and deactivation with the reason and the appropriate next step (appeal path for suspension, closure summary for deactivation). Suspension notifications open an appeal path so the user can contest the decision, and appeals are tracked to resolution.

**Sub-features:**
- Notification on every status change with the reason (in-app and email)
- Suspension notification includes the appeal path and contact
- Deactivation notification includes the closure summary and data-handling outcome
- Appeal submission by the user (from the notification or support)
- Appeal tracking: received, under review, resolved (upheld/rejected)
- Appeal resolution triggers the corresponding status change (activate on uphold)
- Audit logging of notifications and appeal outcomes

**Super Administrator User Journey:**
1. A user is suspended for a policy violation. The notification they receive states the reason and: "If you believe this is an error, submit an appeal."
2. The user submits an appeal with their explanation. It appears in the Account Requests queue (see 6) tagged as a suspension appeal.
3. Super Admin opens the appeal, reviews the original violation evidence alongside the user's explanation, and determines the violation was a misunderstanding.
4. Resolves the appeal as "upheld" (in the user's favor) and activates the account from the appeal record.
5. The user is notified: "Your appeal was reviewed. Your account has been re-activated."
6. For a rejected appeal, the user is notified of the decision and the (limited) further-review option, and the suspension stands.
7. Reviews the appeal queue weekly: all appeals are resolved within the target timeframe, and the outcomes are logged.
8. The full chain — suspension, notification, appeal, resolution, re-activation — is audit-logged and reconstructable from the account record.

**Rules & Edge Cases:**
- Every status change notifies the user; there is no silent suspension or deactivation.
- The appeal path is available for suspensions; deactivation (permanent) does not offer an appeal but does offer the retention-window restore path where applicable.
- Appeals are tracked to resolution with a target timeframe; overdue appeals are highlighted.
- An upheld appeal triggers the re-activation as a linked, audited action.
- Notification and appeal events are audit-logged with the account, actor, and timestamp.
- The reason given to the user is the recorded reason (consistency between the audit and the notification).