# 7. Bulk Operations

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

---

## 7. Bulk Operations

### 7.1 Bulk Activation, Suspension, and Updates
**What it does:** Applies a status change or profile update to a selected set of accounts in one operation — activating, suspending, or updating a cohort (e.g., an institute's students, a graduating class, a set of flagged accounts). Each bulk operation requires a confirmed preview of the affected set, a recorded reason, and produces a per-account result report, so large changes are deliberate, safe, and auditable.

**Sub-features:**
- Select a set via directory filters or explicit selection
- Bulk actions: activate, suspend, deactivate, profile update (e.g., institute re-link, field update)
- Pre-commit preview: the exact affected accounts, the action, and the reason
- Per-account result report: succeeded, failed (with the specific reason per failure)
- Reason recording for the operation
- Audit logging of the operation with the set, action, reason, and result counts

**Super Administrator User Journey:**
1. An institute's 50 students were suspended during a data-integrity investigation and are now cleared. Super Admin filters the directory to the institute + status=Suspended (50 accounts) and selects "Bulk activate".
2. The preview shows the 50 accounts, the action (activate), and a reason field. Super Admin enters "Investigation cleared — [reference]" and confirms.
3. The operation runs: 48 succeed, 2 fail. The result report shows the 2 failures with reasons (one account had a legal hold, one was already deactivated).
4. Super Admin reviews the 2 failures: the legal-hold account is left suspended (correct — the hold blocks activation), and the already-deactivated account is noted as a data inconsistency to resolve.
5. For a profile update — re-linking a cohort of students to a corrected institute ID after a data migration — Super Admin selects the cohort, chooses "Bulk update", previews the before/after institute link for the set, and confirms.
6. The operation applies the update to all selected accounts; the result report confirms 100% success.
7. Reviews the directory to verify the cohort's new state.
8. The operation is audit-logged: the set (count and reference), the action, the reason, and the result counts (succeeded/failed).

**Rules & Edge Cases:**
- A bulk operation is never silent: the preview shows the exact affected set and action before commit.
- Per-account failures do not stop the operation; they are reported with specific reasons for follow-up.
- A reason is required and recorded for every bulk operation.
- Legal holds and other blockers are respected per account (a blocked account fails with the reason, not silently skipped).
- The result report is the record of what actually changed; it is retained with the audit entry.
- The operation is audit-logged as a single event with the set, action, reason, and result counts.

### 7.2 Bulk Assignment of Courses to Student Groups
**What it does:** Assigns courses to a group of students in one operation — for example, enrolling a class cohort in a term's courses, or adding a new course to an existing group. It applies the assignment to every student in the selected group, respects each student's eligibility (membership, seat, age), and produces a per-student result report.

**Sub-features:**
- Select a student group (by institute, class/grade, cohort, or explicit selection)
- Assign one or more courses to the group
- Per-student eligibility check (membership active, seat valid, age/consent where required)
- Pre-commit preview: the group, the courses, and the expected enrollment count
- Per-student result report: enrolled, skipped (with the specific reason per skip)
- Duplicate handling: students already enrolled in a course are not double-enrolled
- Audit logging of the assignment with the group, courses, and result counts

**Super Administrator User Journey:**
1. A new term starts; 120 students in Grade 10 need the term's 4 courses. Super Admin selects the Grade 10 group (120 students) and chooses "Bulk assign courses".
2. Selects the 4 courses and previews: 120 students × 4 courses = 480 expected enrollments, with the eligibility check summary (all memberships active, seats valid).
3. Confirms the assignment. The operation enrolls each student in each course: 478 succeed, 2 skip.
4. The result report shows the 2 skips with reasons (one student's membership lapsed, one is already enrolled in one of the courses — duplicate handling).
5. Super Admin resolves the lapsed membership (routed to billing) so that student can be enrolled; the already-enrolled case needs no action.
6. For an existing group, adds a newly published course: selects the group, assigns the single course, and the students who are not already enrolled gain it.
7. Reviews the course's enrollment list to confirm the group is enrolled.
8. The assignment is audit-logged: the group (count), the courses, and the result counts (enrolled/skipped).

**Rules & Edge Cases:**
- The preview shows the expected enrollment count and the eligibility summary before commit.
- Per-student eligibility is checked; ineligible students are skipped with a specific reason, not force-enrolled.
- Duplicate enrollments are prevented: a student already in a course is not enrolled twice.
- A skip does not stop the operation; it is reported for follow-up.
- The assignment respects course constraints (capacity, prerequisites) per course; a constraint failure is a per-student skip with the reason.
- The operation is audit-logged with the group, courses, and result counts.

### 7.3 Bulk Operation Safety and Audit
**What it does:** Wraps all bulk operations in consistent safety and audit controls: mandatory preview and reason, per-item result reporting, blocker respect, and a complete audit record. It ensures that the power to act on many accounts at once is matched by the controls to do so safely and accountably.

**Sub-features:**
- Mandatory pre-commit preview for every bulk operation (set, action, reason)
- Reason recording for every bulk operation
- Per-item result reporting (succeeded/failed/skipped with reasons)
- Blocker respect: legal holds, eligibility, and constraints are enforced per item
- Operation size guardrails: unusually large operations prompt an extra confirmation
- Complete audit record: set reference, action, reason, result counts, and the result report
- Reversibility guidance: where a bulk action is reversible, the reverse path is indicated

**Super Administrator User Journey:**
1. Super Admin initiates a bulk suspension of 300 accounts (a large cohort). The size guardrail triggers an extra confirmation: "This affects 300 accounts. Confirm the set and reason."
2. Re-verifies the set (the filter summary), confirms the reason, and proceeds.
3. The operation runs with per-item results: 298 suspended, 2 blocked (legal holds), reported with reasons.
4. Reviews the result report and the audit entry: the set reference, the action, the reason, and the counts are all recorded.
5. For a reversible bulk action (a bulk activation), the audit entry indicates the reverse path (bulk suspension) should the change need to be undone.
6. For an irreversible bulk action (a bulk deactivation), the extra confirmation explicitly states the irreversibility and the data-handling consequences before proceeding.
7. Reviews the bulk-operation log periodically: every operation has its preview record, reason, and result report — no unexplained mass changes.
8. The consistent safety and audit controls mean a bulk operation is as accountable as an individual one, scaled.

**Rules & Edge Cases:**
- No bulk operation commits without a preview and a recorded reason.
- Per-item blockers (holds, eligibility, constraints) are respected; they produce reported skips/failures, not silent omissions.
- Unusually large operations trigger an extra confirmation; the threshold is defined by the platform.
- Irreversible bulk actions state the consequences explicitly in the confirmation.
- Every bulk operation has a complete audit record: set, action, reason, result counts, and the result report.
- The bulk-operation log is reviewable, so mass changes are always explainable.