Built for Schools. Powered by Innovation.

Follow Us ON

SCHOOLIXA MODULE GUIDE

Admission & Students Guide

Manage admissions, student profiles, lifecycle, documents, certificates, and identity print.

OVERVIEW

What this module is for

Manage admissions, student profiles, lifecycle, documents, certificates, and identity print.

Primary users Admission staff, school admins, and authorized office users
Documentation status Foundation ready
BEFORE YOU START

Prerequisites

  • Academic session created
  • Class and section configured
  • Student admission permission assigned
SCREENS

Main screens

New Admission Admission Completion Student Directory Student Profile Documents Certificates QR / Barcode Print
WORKFLOWS

Step-by-step workflows

1

Add a student safely

  1. Open Admission & Students > New Admission.
  2. Enter the required student and guardian details.
  3. Save the admission record.
  4. Complete admission setup when the student is ready to become active.
  5. QR/barcode is generated only after admission status becomes active.
2

Review student profile

  1. Open the student directory.
  2. Search or filter the student.
  3. Open the profile.
  4. Use profile cards for attendance, fees, examination, documents, siblings, hostel, transport, and identity print.
DETAILS

Operational detail

Permission checkpoints

  • Users need the relevant admission, student profile, document, certificate, or identity print permission before the matching action is visible or accepted.
  • Profile cards may appear only when the linked module is enabled and the user has permission to open that destination.
  • Lifecycle actions such as activating an admission are protected separately from ordinary profile editing.

Field guidance

Academic session

Use the active session unless you are intentionally reviewing historical placement. Session selection affects class, section, fee, attendance, and exam visibility.

Class and section

Select the configured class and A-Z section that represents the student placement. Sections with unsupported names are rejected.

Admission status

Draft or incomplete records remain operationally limited. Permanent identity QR and barcode values are generated only after the student becomes active.

Guardian and contact details

Enter parent or guardian contact data carefully because parent login, notifications, and emergency communication depend on it.

Documents

Upload only required school documents and keep document names clear. Sensitive values are not needed in public reports or support screenshots.

Profile cards

Use cards to open related records such as attendance, fees, examination, documents, siblings, hostel, transport, and identity print.

Validation and system feedback

  • Admission number and student identity must be unique within the school rules configured by the application.
  • The system validates school ownership, session placement, class-section relationship, required fields, and supported upload formats.
  • QR/barcode generation is intentionally blocked before the admission reaches active status.
  • Server validation runs even if a button or sidebar link is hidden or shown incorrectly.

Common mistakes to avoid

  • Creating profile records in the wrong academic session.
  • Trying to print permanent identity before admission completion.
  • Using section names that are not simple A-Z section codes.
  • Uploading screenshots or files that contain private document numbers when a safe synthetic file is enough for testing.

Recommended next steps

Mark attendance Generate fees Assign transport or hostel if needed Enable parent app access
SCREENSHOTS

Screenshot plan

Final public screenshots will use synthetic QA data only. Sensitive values such as names, phone numbers, emails, admission numbers, document numbers, credentials, cookies, tokens, and internal IDs must be removed or redacted.

Admission form
Student profile cards
Identity print view
SAFE USE

Important safety notes

Use normal Schoolixa workflows

Public docs explain user workflows only. They do not expose internal IDs, direct database operations, credentials, provider prompts, or private system configuration. Permission visibility in the interface does not replace server-side permission checks.