# 3. Account Status Management — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: account_status_management.md — every feature, sub-feature, and rule covered

---

## Test Execution Policy
- Zero tolerance: any deviation from documented behavior = FAILED = bug
- Every bug is immediately logged/reported (Bug ID, feature, sub-feature,
  expected vs actual, severity) and fixed 100% before the group passes
- Feature group passes only at 100% test pass rate

## Coverage Matrix
| Feature | Sub-feature / Rule | Test IDs |
|---------|--------------------|----------|
| 3.1 Activate Accounts | Activate a single account from its record | TC-SA-03-03-001 |
| 3.1 Activate Accounts | Activate previously suspended accounts (restore access, resume subscription per policy) | TC-SA-03-03-002 |
| 3.1 Activate Accounts | Confirm invite-pending accounts as active on first-login completion | TC-SA-03-03-003 |
| 3.1 Activate Accounts | Bulk activation for a selected set | TC-SA-03-03-004 |
| 3.1 Activate Accounts | User notification on activation (for restored accounts) | TC-SA-03-03-005 |
| 3.1 Activate Accounts | Subscription handling on re-activation (resume, prorate per policy) | TC-SA-03-03-006 |
| 3.1 Activate Accounts | Audit logging with actor, reason, and timestamp | TC-SA-03-03-007 |
| 3.1 Activate Accounts | Rule: activation of a suspended account is immediate; the user can log in on the next attempt | TC-SA-03-03-002 |
| 3.1 Activate Accounts | Rule: re-activation resumes subscription per policy; does not silently restart a lapsed payment method | TC-SA-03-03-006 |
| 3.1 Activate Accounts | Rule: activating a deactivated account is not available from this flow (restore path only) | TC-SA-03-03-008 |
| 3.1 Activate Accounts | Rule: bulk activation requires a confirmed preview of the affected count and a recorded reason | TC-SA-03-03-004 |
| 3.1 Activate Accounts | Rule: the user is notified of re-activation | TC-SA-03-03-005 |
| 3.1 Activate Accounts | Rule: every activation is audit-logged with actor, reason, and timestamp | TC-SA-03-03-007 |
| 3.2 Suspend or Deactivate Accounts | Suspend: temporary block with a reason; data retained; reversible; active sessions ended; billing paused per policy | TC-SA-03-03-009 |
| 3.2 Suspend or Deactivate Accounts | Deactivate: permanent closure; triggers the privacy data-handling flow; downstream effects handled | TC-SA-03-03-010 |
| 3.2 Suspend or Deactivate Accounts | Reason presets plus free-text note for both | TC-SA-03-03-011 |
| 3.2 Suspend or Deactivate Accounts | User notification with the reason and the appeal/contact path (suspension) or the closure summary (deactivation) | TC-SA-03-03-012 |
| 3.2 Suspend or Deactivate Accounts | Bulk suspension/deactivation with a confirmed preview | TC-SA-03-03-013 |
| 3.2 Suspend or Deactivate Accounts | Audit logging with actor, reason, and timestamp | TC-SA-03-03-014 |
| 3.2 Suspend or Deactivate Accounts | Rule: suspension is immediate and reversible; deactivation is permanent (restore only via the retention-window path) | TC-SA-03-03-015 |
| 3.2 Suspend or Deactivate Accounts | Rule: suspension pauses recurring billing per policy; deactivation cancels the subscription with refund handling | TC-SA-03-03-016 |
| 3.2 Suspend or Deactivate Accounts | Rule: both actions end active sessions (on the next request) and notify the user with the reason | TC-SA-03-03-017 |
| 3.2 Suspend or Deactivate Accounts | Rule: deactivation triggers the full privacy data-handling flow; it is not a simple status flip | TC-SA-03-03-010 |
| 3.2 Suspend or Deactivate Accounts | Rule: bulk operations require a confirmed preview of the affected count and a recorded reason | TC-SA-03-03-013 |
| 3.2 Suspend or Deactivate Accounts | Rule: every status change is audit-logged with actor, reason, and timestamp | TC-SA-03-03-014 |
| 3.3 Delete Accounts | Deletion eligibility check: account deactivated, retention window elapsed, no legal hold, no open financial obligations | TC-SA-03-03-018 |
| 3.3 Delete Accounts | Downstream check: no active subscription, no allocated seat, no open support tickets | TC-SA-03-03-019 |
| 3.3 Delete Accounts | Explicit confirmation with the irreversibility warning and the eligibility summary | TC-SA-03-03-020 |
| 3.3 Delete Accounts | Removal of the account record with retention of required audit/financial references (anonymized) | TC-SA-03-03-021 |
| 3.3 Delete Accounts | Audit logging of the deletion with the eligibility summary and the acting admin | TC-SA-03-03-022 |
| 3.3 Delete Accounts | Rule: deletion is blocked unless all eligibility checks pass; the specific failing check is shown | TC-SA-03-03-023 |
| 3.3 Delete Accounts | Rule: deletion is irreversible; the confirmation makes this explicit | TC-SA-03-03-020 |
| 3.3 Delete Accounts | Rule: anonymized references remain in audit and financial records; the individual is no longer identifiable | TC-SA-03-03-021 |
| 3.3 Delete Accounts | Rule: deletion is distinct from deactivation | TC-SA-03-03-024 |
| 3.3 Delete Accounts | Rule: legal holds block deletion regardless of retention; the hold must be released first | TC-SA-03-03-025 |
| 3.3 Delete Accounts | Rule: every deletion is audit-logged with the full eligibility summary | TC-SA-03-03-022 |
| 3.4 Status Change Notifications and Appeals | Notification on every status change with the reason (in-app and email) | TC-SA-03-03-026 |
| 3.4 Status Change Notifications and Appeals | Suspension notification includes the appeal path and contact | TC-SA-03-03-027 |
| 3.4 Status Change Notifications and Appeals | Deactivation notification includes the closure summary and data-handling outcome | TC-SA-03-03-028 |
| 3.4 Status Change Notifications and Appeals | Appeal submission by the user (from the notification or support) | TC-SA-03-03-029 |
| 3.4 Status Change Notifications and Appeals | Appeal tracking: received, under review, resolved (upheld/rejected) | TC-SA-03-03-030 |
| 3.4 Status Change Notifications and Appeals | Appeal resolution triggers the corresponding status change (activate on uphold) | TC-SA-03-03-031 |
| 3.4 Status Change Notifications and Appeals | Audit logging of notifications and appeal outcomes | TC-SA-03-03-032 |
| 3.4 Status Change Notifications and Appeals | Rule: every status change notifies the user; there is no silent suspension or deactivation | TC-SA-03-03-026 |
| 3.4 Status Change Notifications and Appeals | Rule: the appeal path is available for suspensions; deactivation offers the retention-window restore path where applicable | TC-SA-03-03-033 |
| 3.4 Status Change Notifications and Appeals | Rule: appeals are tracked to resolution with a target timeframe; overdue appeals are highlighted | TC-SA-03-03-034 |
| 3.4 Status Change Notifications and Appeals | Rule: an upheld appeal triggers the re-activation as a linked, audited action | TC-SA-03-03-031 |
| 3.4 Status Change Notifications and Appeals | Rule: notification and appeal events are audit-logged with the account, actor, and timestamp | TC-SA-03-03-032 |
| 3.4 Status Change Notifications and Appeals | Rule: the reason given to the user is the recorded reason (consistency between the audit and the notification) | TC-SA-03-03-035 |

## 3.1 Activate Accounts

### TC-SA-03-03-001 — Activate a single account from its record
**Type:** Positive
**Covers:** 3.1 → Activate a single account from its record
**Preconditions:** A new account is awaiting enablement (invite accepted, password set, but not yet active).
**Steps:**
1. Open the account record.
2. Select "Activate" and enter a reason.
3. Confirm.
**Expected Result:** The account moves to the active state; the user can log in and use the platform.
**Priority:** Critical

### TC-SA-03-03-002 — Activating a suspended account is immediate; the user can log in on the next attempt
**Type:** Positive
**Covers:** 3.1 → Activate previously suspended accounts (restore access, resume subscription per policy); Rule: activation of a suspended account is immediate; the user can log in on the next attempt
**Preconditions:** A suspended account with a resolved appeal.
**Steps:**
1. Open the account record and select "Activate" with the reason "Appeal upheld — violation cleared".
2. Confirm.
3. Immediately attempt to log in as the user.
**Expected Result:** The account is active immediately; the user's login attempt succeeds on the next try — no delay.
**Priority:** Critical

### TC-SA-03-03-003 — Invite-pending accounts are confirmed as active on first-login completion
**Type:** Positive
**Covers:** 3.1 → Confirm invite-pending accounts as active on first-login completion
**Preconditions:** An invite-pending account has received its invite.
**Steps:**
1. Complete the first login (accept the invite, set the password).
2. Check the account's status.
**Expected Result:** The account moves from "invite pending" to "active" on first-login completion — no separate admin action is required.
**Priority:** High

### TC-SA-03-03-004 — Bulk activation requires a confirmed preview of the affected count and a recorded reason
**Type:** Positive
**Covers:** 3.1 → Bulk activation for a selected set; Rule: bulk activation requires a confirmed preview of the affected count and a recorded reason
**Preconditions:** 50 suspended accounts for an institute are selected in the directory.
**Steps:**
1. Select the set and choose "Activate".
2. Verify the preview shows the count (50) and a reason field.
3. Attempt to confirm without a reason.
4. Enter the reason and confirm.
**Expected Result:** The preview shows the exact affected count; confirmation is blocked without a reason; with the reason, all 50 accounts are activated.
**Priority:** Critical

### TC-SA-03-03-005 — The user is notified of re-activation
**Type:** Positive
**Covers:** 3.1 → User notification on activation (for restored accounts); Rule: the user is notified of re-activation so the change is not silent
**Preconditions:** A suspended account is about to be re-activated.
**Steps:**
1. Re-activate the account.
2. Check the user's notifications (in-app and email).
**Expected Result:** The user receives a notification: "Your account has been re-activated" — the change is not silent.
**Priority:** High

### TC-SA-03-03-006 — Subscription handling on re-activation resumes per policy; a lapsed payment method is not silently restarted
**Type:** Edge
**Covers:** 3.1 → Subscription handling on re-activation (resume, prorate per policy); Rule: re-activation resumes subscription handling per policy; it does not silently restart a lapsed payment method without confirmation
**Preconditions:** A suspended account's subscription was paused; its payment method has lapsed.
**Steps:**
1. Re-activate the account.
2. Observe the subscription handling.
3. Verify whether the lapsed payment method was restarted.
**Expected Result:** The subscription resumes per policy (next billing cycle restored, proration applied); the lapsed payment method is NOT silently restarted — it requires confirmation.
**Priority:** High

### TC-SA-03-03-007 — Every activation is audit-logged with actor, reason, and timestamp
**Type:** Positive
**Covers:** 3.1 → Audit logging with actor, reason, and timestamp; Rule: every activation is audit-logged with actor, reason, and timestamp
**Preconditions:** One individual and one bulk activation have been performed.
**Steps:**
1. Open the audit trail and filter by "activation".
2. Verify each entry.
**Expected Result:** Both activations are audit-logged with the actor, the reason, and the timestamp — individual and bulk alike.
**Priority:** Critical

### TC-SA-03-03-008 — Activating a deactivated account is not available from this flow
**Type:** Negative
**Covers:** 3.1 → Rule: activating a deactivated (permanently closed) account is not available from this flow; that requires the restore path within the retention window
**Preconditions:** A deactivated account exists.
**Steps:**
1. Open the deactivated account's record.
2. Look for the "Activate" action.
**Expected Result:** The "Activate" action is not available for the deactivated account — only the retention-window restore path (Authentication & Access / Data Protection) applies.
**Priority:** High

## 3.2 Suspend or Deactivate Accounts

### TC-SA-03-03-009 — Suspension: temporary block with a reason; data retained; reversible; sessions ended; billing paused
**Type:** Positive
**Covers:** 3.2 → Suspend: temporary block with a reason; data retained; reversible; active sessions ended; billing paused per policy
**Preconditions:** An active account with an active session and recurring billing.
**Steps:**
1. Suspend the account with the reason preset "Policy violation" and a note.
2. Verify the user cannot log in.
3. Verify the active session ends on its next request.
4. Verify recurring billing is paused.
5. Verify the account's data is retained.
6. Re-activate the account (reversibility).
**Expected Result:** The suspension is immediate: login blocked, session ended on next request, billing paused, data retained; the suspension is reversible via re-activation.
**Priority:** Critical

### TC-SA-03-03-010 — Deactivation: permanent closure triggering the full privacy data-handling flow
**Type:** Positive
**Covers:** 3.2 → Deactivate: permanent closure; triggers the privacy data-handling flow (deletion/anonymization per retention); downstream effects handled; Rule: deactivation triggers the full privacy data-handling flow; it is not a simple status flip
**Preconditions:** An active account with a subscription and an institute seat.
**Steps:**
1. Select "Deactivate" and review the data-handling summary (what will be deleted, what is retained and anonymized, downstream effects).
2. Confirm.
3. Verify the personal data handling, subscription cancellation, and seat release.
**Expected Result:** The deactivation executes the full privacy data-handling flow: personal data is handled per policy, the subscription is cancelled with refund per policy, and the institute seat is released — not a simple status flip.
**Priority:** Critical

### TC-SA-03-03-011 — Reason presets plus free-text note are available for both actions
**Type:** Positive
**Covers:** 3.2 → Reason presets plus free-text note for both
**Preconditions:** A suspension and a deactivation are being initiated.
**Steps:**
1. For the suspension, verify the reason presets are listed and a free-text note can be added.
2. For the deactivation, verify the same.
**Expected Result:** Both actions offer reason presets and a free-text note field — the reason is always recordable.
**Priority:** Medium

### TC-SA-03-03-012 — User notification includes the reason and the appeal path (suspension) or closure summary (deactivation)
**Type:** Positive
**Covers:** 3.2 → User notification with the reason and the appeal/contact path (suspension) or the closure summary (deactivation)
**Preconditions:** A suspension and a deactivation are performed.
**Steps:**
1. Suspend an account and inspect the user's notification.
2. Deactivate an account and inspect the user's notification.
**Expected Result:** The suspension notification states the reason and how to appeal; the deactivation notification includes the closure summary and data-handling outcome.
**Priority:** High

### TC-SA-03-03-013 — Bulk suspension/deactivation requires a confirmed preview of the affected count and a recorded reason
**Type:** Positive
**Covers:** 3.2 → Bulk suspension/deactivation with a confirmed preview; Rule: bulk operations require a confirmed preview of the affected count and a recorded reason
**Preconditions:** A set of 20 accounts is selected for bulk suspension.
**Steps:**
1. Select the set and choose "Suspend".
2. Verify the preview shows the count (20) and a reason field.
3. Attempt to confirm without a reason.
4. Enter the reason and confirm.
**Expected Result:** The preview shows the exact affected count; confirmation is blocked without a reason; with the reason, all 20 accounts are suspended.
**Priority:** Critical

### TC-SA-03-03-014 — Every status change is audit-logged with actor, reason, and timestamp
**Type:** Positive
**Covers:** 3.2 → Audit logging with actor, reason, and timestamp; Rule: every status change is audit-logged with actor, reason, and timestamp
**Preconditions:** A suspension and a deactivation have been performed.
**Steps:**
1. Open the audit trail and filter by "status change".
2. Verify each entry.
**Expected Result:** Both the suspension and the deactivation are audit-logged with the actor, the reason, and the timestamp; the deactivation additionally records the data-handling outcome.
**Priority:** Critical

### TC-SA-03-03-015 — Suspension is reversible; deactivation is permanent (restore only via the retention-window path)
**Type:** Edge
**Covers:** 3.2 → Rule: suspension is immediate and reversible; deactivation is permanent (restore only via the retention-window path)
**Preconditions:** One suspended account and one deactivated account.
**Steps:**
1. Re-activate the suspended account — verify success.
2. Attempt to re-activate the deactivated account from the status flow.
3. Verify the deactivated account is only restorable via the retention-window path.
**Expected Result:** The suspension is reversible from the status flow; the deactivation is permanent — restore is only available via the retention-window path.
**Priority:** Critical

### TC-SA-03-03-016 — Suspension pauses recurring billing; deactivation cancels the subscription with refund handling
**Type:** Positive
**Covers:** 3.2 → Rule: suspension pauses recurring billing per policy; deactivation cancels the subscription with refund handling per policy
**Preconditions:** Two active accounts with recurring billing: one to suspend, one to deactivate.
**Steps:**
1. Suspend the first account and verify its recurring billing is paused.
2. Deactivate the second account and verify its subscription is cancelled with refund handling per policy.
**Expected Result:** Suspension pauses billing (reversible); deactivation cancels the subscription with refund handling per policy.
**Priority:** High

### TC-SA-03-03-017 — Both actions end active sessions on the next request and notify the user with the reason
**Type:** Positive
**Covers:** 3.2 → Rule: both actions end active sessions (on the next request) and notify the user with the reason
**Preconditions:** Two active accounts with active sessions: one to suspend, one to deactivate.
**Steps:**
1. Suspend the first account; make a request from its active session.
2. Deactivate the second account; make a request from its active session.
3. Verify both users' notifications include the reason.
**Expected Result:** Both sessions end on their next request; both users are notified with the reason.
**Priority:** High

## 3.3 Delete Accounts

### TC-SA-03-03-018 — Deletion eligibility check: deactivated, retention elapsed, no legal hold, no open financial obligations
**Type:** Positive
**Covers:** 3.3 → Deletion eligibility check: account deactivated, retention window elapsed, no legal hold, no open financial obligations
**Preconditions:** A deactivated account that has passed its retention window with no legal hold and no open financial obligations.
**Steps:**
1. Open the account and run the deletion eligibility check.
2. Verify each check: deactivated (yes), retention elapsed (yes), legal hold (none), open financial obligations (none).
**Expected Result:** All four eligibility checks pass — the account is eligible for deletion.
**Priority:** Critical

### TC-SA-03-03-019 — Downstream check: no active subscription, no allocated seat, no open support tickets
**Type:** Positive
**Covers:** 3.3 → Downstream check: no active subscription, no allocated seat, no open support tickets
**Preconditions:** An eligible account with no active subscription, no allocated seat, and no open support tickets.
**Steps:**
1. Run the downstream check.
2. Verify each: active subscription (none), allocated seat (none), open tickets (none).
**Expected Result:** All three downstream checks pass — no downstream dependencies block the deletion.
**Priority:** Critical

### TC-SA-03-03-020 — Explicit confirmation shows the irreversibility warning and the eligibility summary
**Type:** Positive
**Covers:** 3.3 → Explicit confirmation with the irreversibility warning and the eligibility summary; Rule: deletion is irreversible; the confirmation makes this explicit
**Preconditions:** An eligible account is ready for deletion.
**Steps:**
1. Select "Delete account".
2. Verify the confirmation shows the irreversibility warning and the summary of what will be removed and what anonymized references remain.
**Expected Result:** The confirmation explicitly states the irreversibility and shows the eligibility summary plus the anonymized references that will remain.
**Priority:** Critical

### TC-SA-03-03-021 — Removal retains anonymized audit/financial references; the individual is no longer identifiable
**Type:** Positive
**Covers:** 3.3 → Removal of the account record with retention of required audit/financial references (anonymized); Rule: anonymized references remain in audit and financial records; the individual is no longer identifiable from them
**Preconditions:** An eligible account with historical audit and financial records.
**Steps:**
1. Delete the account.
2. Verify the account record is removed.
3. Verify the audit and financial records retain anonymized references.
4. Verify the individual is no longer identifiable from the references.
**Expected Result:** The account record is removed; anonymized references remain in the audit and financial records for integrity and compliance; the individual is no longer identifiable.
**Priority:** Critical

### TC-SA-03-03-022 — Every deletion is audit-logged with the full eligibility summary and the acting admin
**Type:** Positive
**Covers:** 3.3 → Audit logging of the deletion with the eligibility summary and the acting admin; Rule: every deletion is audit-logged with the full eligibility summary
**Preconditions:** A deletion has been performed.
**Steps:**
1. Open the audit trail and locate the deletion entry.
2. Verify the entry's fields.
**Expected Result:** The deletion is audit-logged with the full eligibility summary, the acting admin, and the timestamp.
**Priority:** Critical

### TC-SA-03-03-023 — Deletion is blocked unless all eligibility checks pass; the specific failing check is shown
**Type:** Negative
**Covers:** 3.3 → Rule: deletion is blocked unless all eligibility checks pass; the specific failing check is shown
**Preconditions:** An eligible account with one open support ticket.
**Steps:**
1. Run the deletion eligibility check.
2. Observe the result.
**Expected Result:** The deletion is blocked with the specific failing check shown ("open support ticket") — not a generic error.
**Priority:** Critical

### TC-SA-03-03-024 — Deletion is distinct from deactivation
**Type:** Edge
**Covers:** 3.3 → Rule: deletion is distinct from deactivation: deactivation handles personal data per privacy policy; deletion removes the record after retention
**Preconditions:** One deactivated (not deleted) account and one deleted account.
**Steps:**
1. Verify the deactivated account's record still exists with personal data handled per privacy policy.
2. Verify the deleted account's record is removed with only anonymized references remaining.
**Expected Result:** The two states are distinct: deactivation retains the record (data handled per policy); deletion removes the record (anonymized references only).
**Priority:** High

### TC-SA-03-03-025 — Legal holds block deletion regardless of retention; the hold must be released first
**Type:** Negative
**Covers:** 3.3 → Rule: legal holds block deletion regardless of retention; the hold must be released first
**Preconditions:** A deactivated account with an elapsed retention window but an active legal hold.
**Steps:**
1. Run the deletion eligibility check.
2. Release the legal hold.
3. Re-run the check.
**Expected Result:** The deletion is blocked while the legal hold is active (regardless of retention); after the hold is released, the check passes.
**Priority:** Critical

## 3.4 Status Change Notifications and Appeals

### TC-SA-03-03-026 — Every status change notifies the user with the reason (in-app and email)
**Type:** Positive
**Covers:** 3.4 → Notification on every status change with the reason (in-app and email); Rule: every status change notifies the user; there is no silent suspension or deactivation
**Preconditions:** An activation, a suspension, and a deactivation are performed.
**Steps:**
1. Perform each status change.
2. Verify the user receives an in-app and email notification with the reason for each.
**Expected Result:** All three status changes produce in-app and email notifications with the reason — no silent status change.
**Priority:** Critical

### TC-SA-03-03-027 — Suspension notification includes the appeal path and contact
**Type:** Positive
**Covers:** 3.4 → Suspension notification includes the appeal path and contact
**Preconditions:** An account is suspended.
**Steps:**
1. Inspect the suspension notification.
2. Verify the appeal path and contact are included.
**Expected Result:** The notification states the reason and: "If you believe this is an error, submit an appeal" — with the appeal path and contact.
**Priority:** High

### TC-SA-03-03-028 — Deactivation notification includes the closure summary and data-handling outcome
**Type:** Positive
**Covers:** 3.4 → Deactivation notification includes the closure summary and data-handling outcome
**Preconditions:** An account is deactivated.
**Steps:**
1. Inspect the deactivation notification.
2. Verify the closure summary and data-handling outcome are included.
**Expected Result:** The notification includes the closure summary (what was deleted, what was retained/anonymized) and the data-handling outcome.
**Priority:** High

### TC-SA-03-03-029 — Appeal submission by the user from the notification or support
**Type:** Positive
**Covers:** 3.4 → Appeal submission by the user (from the notification or support)
**Preconditions:** A suspended user has received the suspension notification.
**Steps:**
1. From the notification, submit an appeal with an explanation.
2. Verify the appeal appears in the Account Requests queue tagged as a suspension appeal.
**Expected Result:** The appeal is submitted and appears in the Account Requests queue tagged as a suspension appeal.
**Priority:** High

### TC-SA-03-03-030 — Appeal tracking: received, under review, resolved (upheld/rejected)
**Type:** Positive
**Covers:** 3.4 → Appeal tracking: received, under review, resolved (upheld/rejected)
**Preconditions:** A suspension appeal has been submitted.
**Steps:**
1. Verify the appeal's state is "received".
2. Move it to "under review".
3. Resolve it as "upheld".
4. Submit a second appeal and resolve it as "rejected".
**Expected Result:** Each appeal is tracked through its states: received → under review → resolved (upheld or rejected) — the full lifecycle is visible.
**Priority:** High

### TC-SA-03-03-031 — An upheld appeal triggers the re-activation as a linked, audited action
**Type:** Positive
**Covers:** 3.4 → Appeal resolution triggers the corresponding status change (activate on uphold); Rule: an upheld appeal triggers the re-activation as a linked, audited action
**Preconditions:** A suspension appeal is resolved as "upheld".
**Steps:**
1. Resolve the appeal as "upheld" and activate the account from the appeal record.
2. Verify the user's notification.
3. Verify the audit trail links the appeal resolution to the re-activation.
**Expected Result:** The re-activation is triggered as a linked, audited action; the user is notified: "Your appeal was reviewed. Your account has been re-activated."
**Priority:** Critical

### TC-SA-03-03-032 — Notification and appeal events are audit-logged with the account, actor, and timestamp
**Type:** Positive
**Covers:** 3.4 → Audit logging of notifications and appeal outcomes; Rule: notification and appeal events are audit-logged with the account, actor, and timestamp
**Preconditions:** A suspension, its notification, an appeal, and its resolution have occurred.
**Steps:**
1. Open the audit trail for the account.
2. Verify the entries for the notification and the appeal outcome.
**Expected Result:** Both the notification and the appeal outcome are audit-logged with the account, the actor, and the timestamp.
**Priority:** Critical

### TC-SA-03-03-033 — The appeal path is available for suspensions; deactivation offers the retention-window restore path
**Type:** Edge
**Covers:** 3.4 → Rule: the appeal path is available for suspensions; deactivation (permanent) does not offer an appeal but does offer the retention-window restore path where applicable
**Preconditions:** One suspended account and one deactivated account.
**Steps:**
1. Verify the suspended account's notification offers the appeal path.
2. Verify the deactivated account's notification does NOT offer an appeal but references the retention-window restore path where applicable.
**Expected Result:** The suspension offers an appeal; the deactivation does not offer an appeal but references the retention-window restore path.
**Priority:** High

### TC-SA-03-03-034 — Appeals are tracked to resolution with a target timeframe; overdue appeals are highlighted
**Type:** Positive
**Covers:** 3.4 → Rule: appeals are tracked to resolution with a target timeframe; overdue appeals are highlighted
**Preconditions:** An appeal is past its target timeframe and unresolved.
**Steps:**
1. Open the appeal queue.
2. Verify the overdue appeal is highlighted.
**Expected Result:** The overdue appeal is highlighted — it is not buried; the target timeframe is visible.
**Priority:** Medium

### TC-SA-03-03-035 — The reason given to the user is the recorded reason (consistency between the audit and the notification)
**Type:** Positive
**Covers:** 3.4 → Rule: the reason given to the user is the recorded reason (consistency between the audit and the notification)
**Preconditions:** A suspension is performed with the reason "Policy violation — repeated incidents".
**Steps:**
1. Inspect the user's notification reason.
2. Inspect the audit trail's recorded reason.
**Expected Result:** The reason in the notification matches the reason in the audit trail exactly — no discrepancy.
**Priority:** High