# 6. Account Requests — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: account_requests.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 |
|---------|--------------------|----------|
| 6.1 Process Account-Related Requests | Request queue: all open requests with type, requester, priority, and age | TC-SA-03-06-001 |
| 6.1 Process Account-Related Requests | Request types: registration help, profile change, verification issue, suspension appeal, deletion/closure, access issue | TC-SA-03-06-002 |
| 6.1 Process Account-Related Requests | Request detail: the request, the account, the context, and the history | TC-SA-03-06-003 |
| 6.1 Process Account-Related Requests | Ownership and assignment: each request has an owner (Super Admin or delegated) | TC-SA-03-06-004 |
| 6.1 Process Account-Related Requests | Target timeframe per type with overdue highlighting | TC-SA-03-06-005 |
| 6.1 Process Account-Related Requests | Resolution with a recorded outcome and user notification | TC-SA-03-06-006 |
| 6.1 Process Account-Related Requests | Audit logging of request lifecycle events | TC-SA-03-06-007 |
| 6.1 Process Account-Related Requests | Rule: every request has an owner and a target timeframe; overdue requests are highlighted, not buried | TC-SA-03-06-005 |
| 6.1 Process Account-Related Requests | Rule: resolution requires a recorded outcome; a request is not closed without it | TC-SA-03-06-008 |
| 6.1 Process Account-Related Requests | Rule: the user is notified of the resolution (and of key interim updates per policy) | TC-SA-03-06-006 |
| 6.1 Process Account-Related Requests | Rule: deletion and suspension-appeal requests route to their owning flows (3.3, 3.4) with the request as the trigger | TC-SA-03-06-009 |
| 6.1 Process Account-Related Requests | Rule: delegation is possible (to sub-admins with the permission); the original requester is unaffected | TC-SA-03-06-004 |
| 6.1 Process Account-Related Requests | Rule: the full request lifecycle is audit-logged with the account, owner, and timestamps | TC-SA-03-06-007 |
| 6.2 Handle Course Access Issues | Access-issue intake: the user, the course, and the symptom (cannot open, cannot see, partial access) | TC-SA-03-06-010 |
| 6.2 Handle Course Access Issues | Diagnosis checks: enrollment state, membership/seat validity, role/permission, content availability, account status | TC-SA-03-06-011 |
| 6.2 Handle Course Access Issues | Root-cause identification with the specific failing check | TC-SA-03-06-012 |
| 6.2 Handle Course Access Issues | Fix application: correct the enrollment, restore the membership/seat, adjust the permission, or escalate the content issue | TC-SA-03-06-013 |
| 6.2 Handle Course Access Issues | Verification: confirm the user can now access the course | TC-SA-03-06-014 |
| 6.2 Handle Course Access Issues | User notification with the resolution | TC-SA-03-06-015 |
| 6.2 Handle Course Access Issues | Audit logging of the diagnosis and fix | TC-SA-03-06-016 |
| 6.2 Handle Course Access Issues | Rule: diagnosis is structured (enrollment, membership, permission, content, status) so the root cause is identified, not guessed | TC-SA-03-06-011 |
| 6.2 Handle Course Access Issues | Rule: the fix matches the root cause; not a permission change that masks it | TC-SA-03-06-017 |
| 6.2 Handle Course Access Issues | Rule: fixes that belong to other modules (billing, content publishing) are routed to those modules, not forced here | TC-SA-03-06-018 |
| 6.2 Handle Course Access Issues | Rule: verification is part of the resolution: the user's access is confirmed, not assumed | TC-SA-03-06-014 |
| 6.2 Handle Course Access Issues | Rule: the user is notified with the resolution and the cause | TC-SA-03-06-015 |
| 6.2 Handle Course Access Issues | Rule: the full diagnosis and fix are audit-logged for the request and the account | TC-SA-03-06-016 |
| 6.3 Request Tracking and SLA Monitoring | SLA targets per request type with per-request countdown | TC-SA-03-06-019 |
| 6.3 Request Tracking and SLA Monitoring | Overdue and at-risk views (approaching the target) | TC-SA-03-06-020 |
| 6.3 Request Tracking and SLA Monitoring | Queue health: open count by type, average resolution time, overdue count | TC-SA-03-06-021 |
| 6.3 Request Tracking and SLA Monitoring | Resolution-time metrics by type and by owner | TC-SA-03-06-022 |
| 6.3 Request Tracking and SLA Monitoring | Escalation for overdue requests (notify the owner, then the Super Admin) | TC-SA-03-06-023 |
| 6.3 Request Tracking and SLA Monitoring | Reporting export for service reviews | TC-SA-03-06-024 |
| 6.3 Request Tracking and SLA Monitoring | Audit logging of SLA events (breach, escalation) | TC-SA-03-06-025 |
| 6.3 Request Tracking and SLA Monitoring | Rule: every request type has an SLA target; the per-request countdown makes the deadline visible | TC-SA-03-06-019 |
| 6.3 Request Tracking and SLA Monitoring | Rule: overdue requests escalate automatically (owner, then Super Admin); they are not left to be noticed | TC-SA-03-06-023 |
| 6.3 Request Tracking and SLA Monitoring | Rule: metrics are by type and by owner, so trends and workload imbalances are visible | TC-SA-03-06-022 |
| 6.3 Request Tracking and SLA Monitoring | Rule: SLA breaches are recorded and reviewable; they are not hidden by resolution | TC-SA-03-06-026 |
| 6.3 Request Tracking and SLA Monitoring | Rule: the SLA report is exportable for service reviews and compliance | TC-SA-03-06-024 |
| 6.3 Request Tracking and SLA Monitoring | Rule: SLA events are audit-logged with the request, target, actual, and escalation path | TC-SA-03-06-025 |

## 6.1 Process Account-Related Requests

### TC-SA-03-06-001 — Request queue shows all open requests with type, requester, priority, and age
**Type:** Positive
**Covers:** 6.1 → Request queue: all open requests with type, requester, priority, and age
**Preconditions:** 12 open requests of various types exist.
**Steps:**
1. Open the Account Requests queue.
2. Verify each open request shows its type, requester, priority, and age.
**Expected Result:** All 12 open requests are listed with type, requester, priority, and age — no request is missing.
**Priority:** Critical

### TC-SA-03-06-002 — All six request types are supported
**Type:** Positive
**Covers:** 6.1 → Request types: registration help, profile change, verification issue, suspension appeal, deletion/closure, access issue
**Preconditions:** One request of each of the six types exists.
**Steps:**
1. Open the queue and verify each of the six types is present and correctly categorized.
**Expected Result:** All six request types are supported and correctly categorized in the queue.
**Priority:** High

### TC-SA-03-06-003 — Request detail shows the request, the account, the context, and the history
**Type:** Positive
**Covers:** 6.1 → Request detail: the request, the account, the context, and the history
**Preconditions:** A registration-help request with prior interactions exists.
**Steps:**
1. Open the request detail.
2. Verify the request description, the linked account, the context, and the interaction history.
**Expected Result:** The detail view shows the request, the account, the context, and the full history — everything needed to resolve it.
**Priority:** High

### TC-SA-03-06-004 — Ownership and assignment: each request has an owner; delegation is possible
**Type:** Positive
**Covers:** 6.1 → Ownership and assignment: each request has an owner (Super Admin or delegated); Rule: delegation is possible (to sub-admins with the permission); the original requester is unaffected
**Preconditions:** Three access-issue requests exist; a support sub-admin with the permission is available.
**Steps:**
1. Verify each request has an owner.
2. Assign the three access issues to the support sub-admin (delegated).
3. Verify the original requester is unaffected by the delegation.
**Expected Result:** Every request has an owner; the three access issues are delegated to the sub-admin; the original requester's experience is unaffected.
**Priority:** High

### TC-SA-03-06-005 — Target timeframe per type with overdue highlighting
**Type:** Positive
**Covers:** 6.1 → Target timeframe per type with overdue highlighting; Rule: every request has an owner and a target timeframe; overdue requests are highlighted, not buried
**Preconditions:** A registration-help request is 4 days old (past its target).
**Steps:**
1. Open the queue.
2. Verify the overdue request is highlighted.
3. Verify the target timeframe is shown per type.
**Expected Result:** The overdue request is highlighted (not buried); the target timeframe is visible per type.
**Priority:** High

### TC-SA-03-06-006 — Resolution with a recorded outcome and user notification
**Type:** Positive
**Covers:** 6.1 → Resolution with a recorded outcome and user notification; Rule: the user is notified of the resolution (and of key interim updates per policy)
**Preconditions:** A registration-help request is ready to resolve.
**Steps:**
1. Resolve the request with a recorded outcome.
2. Verify the user is notified of the resolution.
**Expected Result:** The resolution records the outcome and notifies the user — the request is closed with communication.
**Priority:** High

### TC-SA-03-06-007 — The full request lifecycle is audit-logged with the account, owner, and timestamps
**Type:** Positive
**Covers:** 6.1 → Audit logging of request lifecycle events; Rule: the full request lifecycle is audit-logged with the account, owner, and timestamps
**Preconditions:** A request has gone through submission, assignment, resolution, and notification.
**Steps:**
1. Open the audit trail for the request.
2. Verify each lifecycle event.
**Expected Result:** Every lifecycle event (submission, assignment, resolution, notification) is audit-logged with the account, the owner, and the timestamps.
**Priority:** Critical

### TC-SA-03-06-008 — A request is not closed without a recorded outcome
**Type:** Negative
**Covers:** 6.1 → Rule: resolution requires a recorded outcome; a request is not closed without it
**Preconditions:** An open request is ready to close.
**Steps:**
1. Attempt to close the request without entering an outcome.
**Expected Result:** The close is blocked — a recorded outcome is required; the request cannot be closed without it.
**Priority:** High

### TC-SA-03-06-009 — Deletion and suspension-appeal requests route to their owning flows with the request as the trigger
**Type:** Positive
**Covers:** 6.1 → Rule: deletion and suspension-appeal requests route to their owning flows (3.3, 3.4) with the request as the trigger
**Preconditions:** A deletion request and a suspension-appeal request exist.
**Steps:**
1. Open the deletion request and route it to the deletion flow (3.3).
2. Open the suspension appeal and route it to the appeal flow (3.4).
3. Verify the request is the trigger and is linked to the flow.
**Expected Result:** Both requests route to their owning flows with the request as the trigger — the flows are linked back to the request.
**Priority:** High

## 6.2 Handle Course Access Issues

### TC-SA-03-06-010 — Access-issue intake captures the user, the course, and the symptom
**Type:** Positive
**Covers:** 6.2 → Access-issue intake: the user, the course, and the symptom (cannot open, cannot see, partial access)
**Preconditions:** A student reports: "I can't open my course."
**Steps:**
1. Open the access-issue request.
2. Verify the intake captures the user, the course, and the symptom ("cannot open").
**Expected Result:** The intake records the user, the course, and the symptom — the issue is fully captured.
**Priority:** High

### TC-SA-03-06-011 — Diagnosis checks cover enrollment, membership/seat, role/permission, content availability, and account status
**Type:** Positive
**Covers:** 6.2 → Diagnosis checks: enrollment state, membership/seat validity, role/permission, content availability, account status; Rule: diagnosis is structured (enrollment, membership, permission, content, status) so the root cause is identified, not guessed
**Preconditions:** An access-issue request is open.
**Steps:**
1. Run the diagnosis checks for the student and the course.
2. Verify all five checks are performed: enrollment, membership/seat, role/permission, content availability, account status.
**Expected Result:** All five structured checks are performed — the diagnosis is systematic, not guessed.
**Priority:** Critical

### TC-SA-03-06-012 — Root-cause identification names the specific failing check
**Type:** Positive
**Covers:** 6.2 → Root-cause identification with the specific failing check
**Preconditions:** A student cannot open a course; the course's first module is in "draft" (not published).
**Steps:**
1. Run the diagnosis checks.
2. Verify the root cause is identified as content availability (the module is not published).
**Expected Result:** The root cause is identified with the specific failing check (content availability) — not a vague "access problem".
**Priority:** Critical

### TC-SA-03-06-013 — Fix application matches the root cause: enrollment, membership/seat, permission, or content escalation
**Type:** Positive
**Covers:** 6.2 → Fix application: correct the enrollment, restore the membership/seat, adjust the permission, or escalate the content issue
**Preconditions:** Four access issues with distinct root causes: enrollment, membership lapse, permission gap, content not published.
**Steps:**
1. For the enrollment issue, correct the enrollment.
2. For the membership lapse, restore the membership/seat.
3. For the permission gap, adjust the permission (correct the group assignment).
4. For the content issue, escalate to the content owner (or publish if within authority).
**Expected Result:** Each fix matches its root cause — the correct fix is applied for each distinct problem.
**Priority:** Critical

### TC-SA-03-06-014 — Verification confirms the user can now access the course
**Type:** Positive
**Covers:** 6.2 → Verification: confirm the user can now access the course; Rule: verification is part of the resolution: the user's access is confirmed, not assumed
**Preconditions:** A fix has been applied to an access issue.
**Steps:**
1. After the fix, verify the user can now open the course and its components.
**Expected Result:** The user's access is confirmed (not assumed) — the course and its components are accessible.
**Priority:** Critical

### TC-SA-03-06-015 — The user is notified with the resolution and the cause
**Type:** Positive
**Covers:** 6.2 → User notification with the resolution; Rule: the user is notified with the resolution and the cause
**Preconditions:** An access issue has been resolved.
**Steps:**
1. Verify the user's notification.
**Expected Result:** The user is notified with the resolution and the cause (in plain terms).
**Priority:** Medium

### TC-SA-03-06-016 — The full diagnosis and fix are audit-logged for the request and the account
**Type:** Positive
**Covers:** 6.2 → Audit logging of the diagnosis and fix; Rule: the full diagnosis and fix are audit-logged for the request and the account
**Preconditions:** An access issue has been diagnosed and fixed.
**Steps:**
1. Open the audit trail for the request and the account.
2. Verify the diagnosis, root cause, and fix are logged.
**Expected Result:** The diagnosis, root cause, and fix are audit-logged against both the request and the account.
**Priority:** Critical

### TC-SA-03-06-017 — The fix matches the root cause; a permission change does not mask an enrollment problem
**Type:** Negative
**Covers:** 6.2 → Rule: the fix matches the root cause: an enrollment fix for an enrollment problem, not a permission change that masks it
**Preconditions:** A student's access issue is caused by a missing enrollment (not a permission gap).
**Steps:**
1. Run the diagnosis — the failing check is enrollment.
2. Verify the applied fix is an enrollment correction, not a permission change.
**Expected Result:** The fix is an enrollment correction — a permission change is not applied to mask the enrollment problem.
**Priority:** High

### TC-SA-03-06-018 — Fixes that belong to other modules are routed to those modules, not forced here
**Type:** Positive
**Covers:** 6.2 → Rule: fixes that belong to other modules (billing, content publishing) are routed to those modules, not forced here
**Preconditions:** Two access issues: one caused by a payment problem (billing), one by unpublished content (content publishing).
**Steps:**
1. For the payment problem, verify the fix is routed to Payment & Billing.
2. For the unpublished content, verify the fix is routed to Content Management.
**Expected Result:** Both fixes are routed to their owning modules — not forced within the access-issue flow.
**Priority:** High

## 6.3 Request Tracking and SLA Monitoring

### TC-SA-03-06-019 — SLA targets per request type with per-request countdown
**Type:** Positive
**Covers:** 6.3 → SLA targets per request type with per-request countdown; Rule: every request type has an SLA target; the per-request countdown makes the deadline visible
**Preconditions:** Open requests of multiple types exist.
**Steps:**
1. Open the Request SLA view.
2. Verify each request type has an SLA target and each request shows a countdown.
**Expected Result:** Every request type has an SLA target; each request shows a per-request countdown — the deadline is visible.
**Priority:** High

### TC-SA-03-06-020 — Overdue and at-risk views show approaching and breached targets
**Type:** Positive
**Covers:** 6.3 → Overdue and at-risk views (approaching the target)
**Preconditions:** 12 open requests: 1 overdue, 2 at-risk (within 20% of their target).
**Steps:**
1. Open the overdue view — verify the 1 overdue request.
2. Open the at-risk view — verify the 2 at-risk requests.
**Expected Result:** The overdue view shows the 1 breached request; the at-risk view shows the 2 approaching their target.
**Priority:** High

### TC-SA-03-06-021 — Queue health shows open count by type, average resolution time, and overdue count
**Type:** Positive
**Covers:** 6.3 → Queue health: open count by type, average resolution time, overdue count
**Preconditions:** The queue has open requests of multiple types with resolution history.
**Steps:**
1. Open the queue health view.
2. Verify the open count by type, the average resolution time, and the overdue count.
**Expected Result:** The queue health shows the open count by type, the average resolution time, and the overdue count — a complete health picture.
**Priority:** Medium

### TC-SA-03-06-022 — Resolution-time metrics by type and by owner reveal trends and workload imbalances
**Type:** Positive
**Covers:** 6.3 → Resolution-time metrics by type and by owner; Rule: metrics are by type and by owner, so trends and workload imbalances are visible
**Preconditions:** Resolution history exists across types and owners; appeals average 2.1 days against a 2-day target.
**Steps:**
1. Open the resolution-time metrics by type.
2. Open the metrics by owner.
3. Verify the appeals trend (2.1 days vs 2-day target) is visible.
**Expected Result:** The metrics by type and by owner reveal the appeals trend and any workload imbalances — actionable insight.
**Priority:** Medium

### TC-SA-03-06-023 — Overdue requests escalate automatically: owner, then Super Admin
**Type:** Positive
**Covers:** 6.3 → Escalation for overdue requests (notify the owner, then the Super Admin); Rule: overdue requests escalate automatically (owner, then Super Admin); they are not left to be noticed
**Preconditions:** A request is past its SLA target and unresolved.
**Steps:**
1. Verify the owner is notified of the breach.
2. Verify the Super Admin is notified (second escalation).
**Expected Result:** The overdue request escalates automatically — the owner is notified first, then the Super Admin — it is not left to be noticed.
**Priority:** Critical

### TC-SA-03-06-024 — The SLA report is exportable for service reviews and compliance
**Type:** Positive
**Covers:** 6.3 → Reporting export for service reviews; Rule: the SLA report is exportable for service reviews and compliance
**Preconditions:** A month of SLA data exists (volumes, resolution times, breaches, escalations by type).
**Steps:**
1. Export the monthly SLA report.
2. Verify the report contains volumes, resolution times, breaches, and escalations by type.
**Expected Result:** The SLA report is exported with volumes, resolution times, breaches, and escalations by type — ready for service reviews and compliance.
**Priority:** Medium

### TC-SA-03-06-025 — SLA events (breach, escalation) are audit-logged with the request, target, actual, and escalation path
**Type:** Positive
**Covers:** 6.3 → Audit logging of SLA events (breach, escalation); Rule: SLA events are audit-logged with the request, target, actual, and escalation path
**Preconditions:** An SLA breach and its escalation have occurred.
**Steps:**
1. Open the audit trail and filter by "SLA".
2. Verify the breach and escalation entries.
**Expected Result:** Both the breach and the escalation are audit-logged with the request, the target, the actual, and the escalation path.
**Priority:** High

### TC-SA-03-06-026 — SLA breaches are recorded and reviewable; not hidden by resolution
**Type:** Positive
**Covers:** 6.3 → Rule: SLA breaches are recorded and reviewable; they are not hidden by resolution
**Preconditions:** A request breached its SLA and was later resolved.
**Steps:**
1. Resolve the breached request.
2. Open the breach log.
3. Verify the breach is still recorded and reviewable.
**Expected Result:** The breach remains recorded and reviewable after resolution — it is not hidden by the resolution.
**Priority:** High