# 5. License & Seat Management User Type: **Super Administrator** Source: *Mi Digital Academy - Education CRM Features Document* --- ## 5. License & Seat Management ### 5.1 Allocate Student Seats Under Institute Licenses **What it does:** Manages the allocation of student seats under an institute's license: each institute license has a seat count, and student accounts linked to the institute occupy seats. Allocation tracks which seats are used, keeps usage within the licensed count, and surfaces availability so the Super Administrator (and institute admins) can manage enrollment against the license. **Sub-features:** - License seat tracking: total seats, allocated, available per institute license - Seat allocation on student-institute linking (a linked student with a seat occupies one) - Allocation cap enforcement: a seat cannot be allocated beyond the licensed count - Seat list per institute: which students hold seats, allocation dates - Availability view: remaining seats, projected usage - Over-allocation prevention with a clear block message - Audit logging of allocations **Super Administrator User Journey:** 1. An institute with a 100-seat license has 95 students linked. Super Admin reviews the license view: 95 allocated, 5 available. 2. The institute requests to add 10 more students. Super Admin sees only 5 seats are available and informs the institute: 5 can be added now; the other 5 require a license upgrade. 3. Allocates the 5 seats as the 5 students are linked; the license view updates to 100 allocated, 0 available. 4. A 101st student link attempt is blocked: "No available seats under this license." The institute is prompted to upgrade. 5. The institute upgrades to a 150-seat license. Super Admin confirms the new seat count; 50 seats are now available. 6. Allocates the remaining 5 students; the license view shows 105 allocated, 45 available. 7. Reviews the seat list: each allocated seat shows the student, allocation date, and status. 8. The allocation events are audit-logged: each seat, the student, the institute, and the timestamp. **Rules & Edge Cases:** - Allocation cannot exceed the licensed seat count; the cap is enforced at link time with a clear block. - A seat is allocated when a student is linked to the institute with a seat; it is released when the student is unlinked or re-linked elsewhere. - License upgrades increase available seats immediately; downgrades are handled with a plan for excess seats (see 5.3). - The seat list is the source of truth for usage; it is consistent with the student-institute links. - Allocation and release are audit-logged with the student, institute, and timestamp. - Availability is always visible so enrollment decisions are made against real capacity. ### 5.2 Transfer Licenses Between Students **What it does:** Supports moving a seat/license from one student to another within an institute — for example, when a student leaves and another takes their place, or when a seat is reassigned. The transfer releases the seat from the outgoing student and allocates it to the incoming student, keeping the license usage unchanged and the audit trail complete. **Sub-features:** - Transfer a seat from one student to another within the same institute - Outgoing student's seat released; incoming student's seat allocated in one operation - License usage unchanged by a transfer (one seat moves, not added) - Incoming student eligibility check (valid account, correct institute, no existing seat) - Outgoing student handling (unlink, or retain account without the seat) - Audit logging of the transfer (from student, to student, institute, timestamp) **Super Administrator User Journey:** 1. A student withdraws from an institute, and a new student is ready to take the place. The institute requests a seat transfer. 2. Super Admin opens the institute's license view and selects the outgoing student's seat, choosing "Transfer to another student". 3. Selects the incoming student (verified: valid account, linked to the institute, no existing seat). 4. Confirms the transfer: the outgoing student's seat is released and the incoming student's seat is allocated in one operation. License usage is unchanged (still 100/100). 5. The outgoing student's account is handled per the request: unlinked from the institute (account retained) or, if they are leaving the platform, routed to the deactivation flow. 6. The incoming student now has full institute access under the seat; the institute's admin sees the swap in the seat list. 7. Reviews the transfer audit entry: from student, to student, institute, and timestamp. 8. The seat list reflects the transfer immediately; no gap or double-allocation occurred. **Rules & Edge Cases:** - A transfer is atomic: the release and the allocation happen together, so usage never shows a gap or a double-count. - The incoming student must be eligible (valid account, correct institute, no existing seat); ineligible transfers are blocked with the reason. - A transfer does not change the license total; it moves one seat. - The outgoing student's account handling is explicit (retain without seat, or deactivate) — not implicit. - Transfers are audit-logged with both students, the institute, and the timestamp. - A transfer to a student who already holds a seat is blocked (one seat per student per institute). ### 5.3 Remove Student Accounts from Licenses **What it does:** Releases a student's seat from an institute's license without necessarily deleting the student account: the student is removed from the license (seat returned to the pool) while the account's fate is handled separately (retained, unlinked, or deactivated). This is the seat-side operation for withdrawals, graduations, and license downgrades. **Sub-features:** - Remove a student from the license (release the seat) with a reason - Seat returns to the institute's available pool immediately - Student account handling options: retain (unlinked), move to another institute, or deactivate - Bulk removal for a set of students (e.g., a graduating cohort) - License downgrade support: plan and execute seat reduction when a license shrinks - Audit logging of removals with the reason and account handling **Super Administrator User Journey:** 1. A cohort of 20 students graduates. The institute requests their removal from the license. Super Admin selects the 20 students in the seat list and chooses "Remove from license". 2. Enters the reason "Graduated — [year]" and selects the account handling: "Retain accounts, unlink from institute" (the students keep their personal accounts and progress). 3. Confirms the bulk removal: 20 seats are released to the institute's pool, and the 20 students are unlinked from the institute. 4. The license view updates: 20 seats now available. 5. For a license downgrade (the institute moves from 100 to 80 seats), Super Admin reviews the current usage (90 allocated) and sees 10 excess seats must be freed. 6. Works with the institute to identify the 10 students to remove (withdrawals, transfers), and executes the removals until usage is within the new 80-seat count. 7. Confirms the downgrade: the license is now 80 seats, usage is within the count, and the excess is resolved. 8. Each removal (individual and bulk) is audit-logged with the reason, the account handling, and the timestamp. **Rules & Edge Cases:** - Removal releases the seat immediately; the account handling is a separate, explicit choice. - Bulk removal requires a confirmed preview (count, reason, account handling) before execution. - A license downgrade cannot leave usage above the new count; excess seats must be freed first (the system blocks a downgrade that would over-allocate). - Removed students' accounts are never silently deleted; the handling is explicit (retain, move, or deactivate via its own flow). - Removals are audit-logged with the reason and the account handling. - The seat pool reflects removals immediately, so availability is always accurate.