# 2. Account Creation & Editing

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

---

## 2. Account Creation & Editing

### 2.1 Create User Accounts Manually
**What it does:** Lets the Super Administrator create an account on behalf of a user — typically staff (sub-admins), institutes, or affiliates who do not self-register, or a student where the institute or support creates the record. The created account follows the same verification, role, and policy rules as a self-registered one, with a clear "created by admin" provenance.

**Sub-features:**
- Creation form per account type (Sub Admin, Student, Parent, Affiliate, Institute) with type-specific required fields
- Provisional credentials: system-generated temporary password (or invite link) delivered to the user's email/phone
- Forced first-login password change for provisionally-credentialed accounts
- Role assignment at creation (for staff) or at first login (guided)
- Institute/staff creation: create the institute account and its staff accounts together
- Verification state set appropriately (admin-created email marked pending user confirmation where policy requires)
- Audit logging of admin-created accounts with the creating admin

**Super Administrator User Journey:**
1. A new institute signs a contract. Super Admin opens User Account Management → Create Account and selects type "Institute".
2. Enters the institute's details: name, contact person, email, phone, address, and the contracted license seat count.
3. Saves; the institute account is created (active) and the contact person receives an invite email with a temporary credential and a first-login password-change requirement.
4. Creates the institute's staff accounts: for each, selects type "Sub Admin", enters name and email, assigns the appropriate role (Teacher/Content Creator, Billing Administrator), and issues an invite.
5. For a student the institute wants added before the bulk upload, Super Admin creates a single student account with the institute link and a provisional credential.
6. Reviews the created accounts in the directory: all show "created by [admin]" provenance and their verification state.
7. Follows up as staff accept invites and set their passwords; the accounts move from "invite pending" to "active, verified" as they complete first login.
8. The creation events are audit-logged: each account, the creating admin, the role assigned, and the timestamp.

**Rules & Edge Cases:**
- Admin-created accounts are marked with provenance (created by which admin) and are distinguishable from self-registrations.
- Provisional credentials force a password change at first login; the temporary password is never shown again after issuance.
- Email uniqueness is enforced: an account cannot be created with an email that already exists (the existing account is surfaced instead).
- Role assignment at creation applies immediately; the user's access is correct from first login.
- Admin creation does not bypass verification policy: where user confirmation is required (e.g., phone), the account reflects the pending state until confirmed.
- Every admin-created account is audit-logged with the creating admin and the initial configuration.

### 2.2 Edit User Profile Information
**What it does:** Allows the Super Administrator to update an account's profile information — contact details, name, institute affiliation, and other attributes — with validation, change history, and user notification. Edits by an admin are distinct from self-service edits and are always audit-logged with the acting admin.

**Sub-features:**
- Editable fields per account type (name, email, phone, address, institute link, date of birth via correction flow)
- Validation on save (format, uniqueness for email/phone)
- Change history: before/after values per field, with the acting admin and timestamp
- User notification on admin-initiated profile changes (per policy)
- Sensitive-field edits (email, phone, DOB) require confirmation and route through the relevant verification/correction flow
- Audit logging of every admin edit

**Super Administrator User Journey:**
1. A student's parent contacts support: the student's phone number on the account is outdated. Super Admin opens the student's record and edits the phone field.
2. Enters the new number; the system validates the format and checks uniqueness (the number is not bound to another active account).
3. Saves; the change is recorded with before/after values, the acting admin, and the timestamp.
4. Per policy, the student is notified: "Your phone number was updated by an administrator."
5. Because the phone is used for OTP login/2FA, the new number enters the verification flow: the student confirms it with an OTP before SMS-based features use it.
6. For an email change (a staff member changed jobs and the institute updated the contact), Super Admin edits the email; the new email requires confirmation (a verification link is sent) before it becomes the login email.
7. Reviews the change history tab: every field change for the account is listed with before/after and actor.
8. The edits are audit-logged and appear in the account's activity history.

**Rules & Edge Cases:**
- Email and phone changes are uniqueness-checked; a value bound to another active account is rejected.
- Changing the login email or phone triggers re-verification of the new value before it is used for authentication.
- Date-of-birth changes do not go through a simple edit; they route through the age-correction flow with evidence (see Authentication & Access).
- Admin edits are always attributed to the acting admin and are distinct from self-service edits in the history.
- The user is notified of admin-initiated changes per policy, so unauthorized edits are visible.
- Every edit is audit-logged with before/after state.

### 2.3 Bulk Student Registration (CSV Upload) for Institutes
**What it does:** Supports institutes registering many students at once through a CSV upload: the Super Administrator (or an institute admin with the permission) uploads a file of student records, the system validates each row, reports errors, and creates the valid accounts linked to the institute — with a clear success/error summary and a path to fix and re-upload failures.

**Sub-features:**
- CSV template download with required and optional columns (name, email, phone, DOB, class/grade, guardian contact)
- Upload with row-level validation (format, required fields, duplicates within the file and against existing accounts)
- Pre-commit preview: valid rows, error rows with specific error messages, and duplicate rows
- Commit: create the valid accounts linked to the institute, with provisional credentials or invite links
- Error report download: the failed rows with reasons, for correction and re-upload
- Progress and completion summary (created, failed, duplicates skipped)
- Audit logging of the bulk operation (file, row counts, acting admin)

**Super Administrator User Journey:**
1. An institute enrolls 200 new students. Super Admin (or the institute admin) downloads the CSV template and shares it with the institute to fill in.
2. Receives the completed file and uploads it. The system validates each row: 190 valid, 8 with errors (missing phone, invalid email format), 2 duplicates (emails already on existing accounts).
3. Reviews the pre-commit preview: the valid count, the error list with per-row reasons, and the duplicate list.
4. Downloads the error report, sends it to the institute with the specific fixes needed, and holds the commit.
5. The institute corrects the 8 rows and re-uploads; validation now shows 198 valid, 0 errors, 2 duplicates (skipped, mapped to existing accounts).
6. Commits the upload: 198 student accounts are created, linked to the institute, with invite links sent to each student's email/phone.
7. Reviews the completion summary and the directory filtered by institute + status "invite pending" to track acceptance.
8. The bulk operation is audit-logged: file reference, row counts (created/failed/duplicates), the acting admin, and the timestamp.

**Rules & Edge Cases:**
- Validation is row-level and specific: each error names the row and the problem, so fixes are unambiguous.
- Duplicates (within the file or against existing accounts) are not silently created; they are reported and mapped to the existing account.
- The commit is a deliberate step after preview; nothing is created until the Super Admin confirms.
- Created accounts follow the same policy as individually created ones (verification, provisional credentials, institute link).
- The error report preserves the original rows so the institute can correct and re-upload without re-keying.
- The bulk operation is audit-logged as a single event with the full row-count breakdown.

### 2.4 Account Type-Specific Fields and Requirements
**What it does:** Defines and enforces the fields and requirements that differ by account type — what an institute account needs (license details, contact), what a staff account needs (role), what a student needs (guardian link, age/consent), what an affiliate needs (commission profile) — so every account is complete and correct for its type at creation and editing.

**Sub-features:**
- Type-specific required fields (institute: license seat count, contact; staff: role; student: guardian, DOB; affiliate: commission profile)
- Type-specific verification requirements (minors: parental consent; affiliates: identity verification)
- Type-specific downstream setup (institute: license provisioning; staff: role and permissions; student: seat allocation)
- Completeness indicator per account (which required items are pending)
- Guidance prompts for missing required items
- Consistency between the type's fields and its available actions

**Super Administrator User Journey:**
1. Creating an institute account, Super Admin sees the type-specific fields appear: license seat count, contact person, billing contact. Completes them and saves; the license is provisioned with the seat count.
2. Creating a staff account, the role field is required; Super Admin assigns the role before saving, so the account is correct from first login.
3. Creating a student account for a minor, the form requires the guardian's details and routes to the parental consent flow; the account shows "consent pending" until the guardian completes it.
4. Creating an affiliate account, the commission-profile fields (tier, payout method) appear; Super Admin completes them so the affiliate is ready to earn from the first referral.
5. Reviews the completeness indicator on a recently created student: "phone verification pending, seat allocated" — and follows up on the pending item.
6. When editing an account, only the type-relevant fields are editable; type-inappropriate fields are not shown (e.g., no license fields on a student).
7. The type-specific requirements keep the directory data complete: filters by verification state or license state work because the underlying fields are consistently populated.
8. New account types or field changes are reflected in the forms automatically; the Super Admin does not maintain the field definitions.

**Rules & Edge Cases:**
- Required fields block save until complete; the form shows exactly what is missing.
- Type-specific verification requirements are enforced, not optional (a minor's account cannot be fully active without guardian consent).
- Downstream setup (license, role, seat) happens as part of creation, so the account is usable immediately after.
- The completeness indicator surfaces pending items without blocking the account's existence.
- Fields are type-appropriate: the form never shows fields that do not apply to the account type.
- All type-specific creation and editing is audit-logged like any other account change.