Onboard 1000 students in minutes. Upload a CSV. Done.
Four CSV templates, one drag-drop upload, every row validated and imported in seconds. Profiles, addresses, parents and academics — bulk-imported into Inkwelly with photos auto-downloaded from URLs, dry-run validation, and per-row error reporting that never silently fails.
Why this exists — and why most ERPs handle it badly
Mid-March. The new academic session opens in two weeks. The principal of a CBSE day school in Lucknow has admitted 320 new students from the admission round. Their names, dates of birth, parent mobiles, Aadhaar numbers, addresses, blood groups, and class assignments sit in a 3-tab Excel sheet that the office assistant has been maintaining for the last six weeks. Now everything has to land inside the school ERP — fee ledgers, attendance registers, class lists, parent app accounts, ID cards, transport stops — before the school year begins.
The office has 14 days. Most school ERPs offer 'student creation' as a single one-by-one form: open admission, type 18 fields, click save, repeat. 320 admissions × 4 minutes each = 21 hours of pure typing. Add address forms. Add parent forms. Add roll-number assignment. Add photo uploads. The 14-day buffer evaporates into 6 weeks of office churn — and the school year starts with half the records still in Excel.
We built Bulk Import Students to compress this from weeks to minutes. Four CSV templates — Profile, Address, Parent, Academic — each downloadable from the import page. Fill them in Excel or Google Sheets the way the office already works. Drag-drop the CSV into Inkwelly. The system parses every row, validates against Indian school conventions (12-digit Aadhaar, DD/MM/YYYY dates, valid CBSE class names), checks for duplicates against your existing student list, downloads profile photos from URLs you supplied, and creates the student profiles in the database — all in one batch. 320 admissions land in under 4 minutes.
How it works — four CSVs, one upload page
Navigate to Students → Import in your school's session. The page has four tabs along the top: Profiles, Addresses, Parents, Academics. Each tab has its own CSV template — because student data has different cardinality (1 student → 1 profile, but 1 student → multiple addresses, multiple parents/guardians, multiple academic year records).
Step 1 — Download the template. Each tab's 'Download template' button generates a CSV with the exact column headers Inkwelly expects. The template includes 5 to 8 example rows so the office can see the format expected — date formats, gender values, address types, relationship types. This is critical: Indian schools migrating from Excel typically have inconsistent header names ('Student Name' in one column, 'Name of Student' in another). The downloaded template fixes that — your office fills in the right columns from day one.
Step 2 — Fill the CSV in Excel or Google Sheets. Your office uses the tools they already know. Names, dates of birth in 15/03/2010 or 2010-03-15 format, gender as MALE / FEMALE / OTHER, blood group as A_POSITIVE / B_POSITIVE / AB_NEGATIVE (the standardised codes), Aadhaar in 12 digits, mobile with country code, religion as one of the seven enumerated values, caste category for RTE 25% reservation tracking, and a profilePhotoUrl column if your admission system collected photos as URLs.
Step 3 — Drag-drop the CSV. The upload zone accepts files up to 10MB (~25,000 rows for a typical profile import). Click or drag — the file appears in a green confirmation card with its name and size. Wrong format (xlsx, xls, anything non-CSV) is rejected before upload starts. Wrong size (over 10MB) is rejected with a clear error pointing to the offending file size.
Step 4 — Validate first, import second (optional but recommended). Toggle the Dry Run checkbox. The system runs every row through the same validation and duplicate-check pipeline as a real import — but doesn't write a single row to the database. The Results dialog opens with: total rows parsed, valid count, invalid count with per-row errors, and processing time. Fix the invalid rows in your CSV, re-upload with Dry Run still on, repeat until 0 invalid rows. Then untick Dry Run and click Start Import — the now-clean CSV imports for real.
Step 5 — Photos download themselves. For Profile and Parent imports, a Download Photos checkbox is on by default. If your CSV includes a profilePhotoUrl column with HTTP/HTTPS URLs (max 5MB per photo), Inkwelly downloads each photo, uploads it to your school's media library, and links it to the student's profile — automatically. The office never opens 320 photos and uploads them one at a time.
What each of the four CSV tabs covers
- Profiles tab — 24 fields per student: studentId (your school's internal ID), admissionNumber (the registration number), firstName, middleName, lastName, dateOfBirth, gender, peNumber (PEN — Permanent Education Number issued by your state board), abcId, apaarId (the new NEP 2020 identifier), bloodGroup, religion, nationality, motherTongue, aadhaarNumber, casteCategory, profilePhotoUrl, email, mobile, isRTEStudent. Required: studentId, admissionNumber, firstName, dateOfBirth, gender. Everything else is optional but strongly encouraged for compliance.
- Addresses tab — 8 fields per address row: studentId (links the address to a student), addressType (PERMANENT / CURRENT / CORRESPONDENCE / OFFICE), addressLine1, addressLine2, city, state, country, postalCode. Multiple address rows per student are supported — one student can have a permanent address in their home village and a current address near the school hostel.
- Parents tab — 12 fields per parent row: studentId (links to the student), relationshipType (FATHER / MOTHER / GUARDIAN / OTHER), title, firstName, middleName, lastName, mobile, email, occupation, education, profilePhotoUrl. Multiple parents per student supported — both father and mother as separate rows for the same studentId.
- Academics tab — current-year academic placement: studentId, classId (your school's class), section, rollNumber, registrationNumber, admissionDate. Drives class lists, attendance registers, fee ledgers, and report card generation downstream.
- Required headers per tab. Profile imports must contain studentId, admissionNumber, firstName, dateOfBirth, gender. Address imports must contain studentId, addressType, addressLine1, city, state, country, postalCode. Parent imports must contain studentId, relationshipType, firstName, lastName, mobile. Academic imports must contain studentId, classId, rollNumber. Missing required headers stop the import before any row is processed — with a clear list of missing columns shown in the Results dialog.
- Header order doesn't matter. Inkwelly matches CSV columns by header name, not position. You can rearrange columns however your office prefers — extra columns are ignored, missing optional columns are treated as empty.
- Empty cells are skipped — never overwrite with blanks. If a row has an empty
aadhaarNumbercell, that field stays empty on the student profile (or stays at its current value during a re-import). The system never silently writes blanks over existing data.
Walkthrough — five screens, end to end
Dry Run — validate without writing anything
The single most expensive mistake in a bulk import is committing data that fails validation halfway through. You upload, 180 rows succeed, row 181 has an Aadhaar with 11 digits, and now your database has 180 students you didn't fully verify and 140 students that never made it.
Dry Run prevents this. Toggle the Dry Run checkbox on every tab, click Validate Data, and Inkwelly runs the entire import pipeline — CSV parsing, header validation, per-row field validation, duplicate detection — without persisting a single row. The Results dialog shows: 320 rows parsed, 312 valid, 8 invalid with specific errors per row ('Aadhaar must be 12 digits', 'Date of birth in invalid format', 'Email format invalid', 'studentId already exists for another student'). Fix the 8 rows in your CSV, re-validate, get to 0 invalid, then untick Dry Run and run for real. The actual import becomes a formality — you already know it will succeed.
Indian date formats — both DD/MM/YYYY and YYYY-MM-DD work
Date of birth in your office's Excel sheet is in 15/03/2010 (Indian convention). The Aadhaar PDF print shows it as 15/03/2010. Your transfer certificate from the previous school has it as 15-03-2010. The state board portal exports as 2010-03-15 (ISO format).
Inkwelly's bulk import accepts both DD/MM/YYYY and YYYY-MM-DD out of the box. The validator parses each format, normalises to ISO internally, and stores it in the database — you don't have to transform dates before upload. US-style MM/DD/YYYY is intentionally rejected to prevent ambiguous parsing (a 03/15/2010 row would otherwise be guessed as either March 15 or the 3rd of an invalid 15th month). Your office never has to think about which format their previous Excel was using — both Indian conventions just work.
Aadhaar, mobile, and Indian identifiers — validated, not just stored
The import doesn't just dump rows into the database. It validates every Indian identifier against its real format rule. Aadhaar must be exactly 12 digits — the validator strips spaces, dashes and dots before checking, so 1234 5678 9012 and 1234-5678-9012 both pass and are stored as 123456789012. Mobile must contain at least 10 digits — country code, dashes, parentheses and spaces are allowed and stripped (+91 98765 43210, (+91)-98765-43210, 9876543210 all pass). Email must match a basic email pattern (lower-cased on save). PEN, ABC ID, APAAR ID are stored as supplied — these are tracked by Indian state boards and the NEP 2020 framework, and your school is expected to maintain whatever value the central registry assigns.
Duplicates are checked against your existing student list — studentId, admissionNumber, and aadhaarNumber are unique per organisation. If the CSV row matches an existing student, the row is rejected with a clear duplicate error showing which field collided. Existing students are never silently overwritten.
Photo auto-download — never upload 320 photos one at a time
Most Indian admission portals (state board portals, your school's existing admission CRM, Google Forms) collect photos as URLs — the parent uploads a photo and the system stores a public URL pointing to it. Most school ERPs ignore this and force you to download every photo and re-upload it manually.
Inkwelly handles photos automatically. Add a profilePhotoUrl column to your Profile or Parent CSV with the public photo URL per row. Tick Download Photos (on by default). When the import runs, Inkwelly downloads each photo (max 5MB), uploads it to your school's media library with a sensible filename (student-photos/<studentId>-<name>.jpg), and attaches the resulting media ID to the student's profile photo field. 320 admissions, 320 photos, zero clicks — they appear on the student list, on ID cards, on the parent app profile screen, instantly. URLs that fail to download (404, broken image, oversized) are logged in the per-row results — you can fix them and re-import only those rows.
Per-row results — partial success is the default, not the exception
The nightmare of bulk operations in most school ERPs: one row's Aadhaar is malformed and the entire import rolls back, forcing you to fix one row at a time and re-run from scratch. Inkwelly doesn't work that way.
Each row is processed atomically — success or failure independently. The Results dialog shows: 312 students imported successfully, 8 rows failed with specific errors ('Aadhaar must be 12 digits' on row 47, 'studentId already exists for another student' on row 113, 'Email format invalid' on row 281). The 312 successful imports are saved. The 8 failures stay in your CSV for fixing — re-upload only the corrected rows or fix and re-upload the whole file (duplicates are skipped, so re-running is safe). A downloadable Error Report CSV lists every failed row with its original data and the specific validation messages — you can paste it directly into your office's working sheet and fix in place. The audit log captures every successful import with the user, timestamp, IP address, and the source ('Bulk Import Students').
“March admission ke baad humare paas 280 students ka data Excel mein tha। Pehle ek-ek karke daalte the — 4 din lagte the। Ab CSV se import kiya — Profile, Address, Parent, Academic, sab 4 minute mein ho gaya। Photos bhi automatic download ho gaye। 1 April ko session start kiya, sab kuch ready tha।”
Five real office routines this turns into a 5-minute task
Five routine school office operations that traditionally take days, compressed into a single CSV upload:
1. New session onboarding (March–April) — 320 students admitted across the year, currently sitting in your office's Excel sheet. Without bulk import: 21 hours of typing the profile, plus 12 hours typing addresses, plus 14 hours typing parents, plus 6 hours typing academic placements — 53 office-hours total. With Inkwelly bulk import: download 4 templates, paste your Excel data into each, drag-drop, dry-run, fix 8 invalid rows, run for real. Under 90 minutes total.
2. Mid-year transfer-in admissions — 12 students transferring in mid-session from other schools. Their Transfer Certificates have all the data the school needs (name, DOB, board, parents). Office assistant pastes 12 rows into the profile template, 12 into the parent template, 12 into the address template, runs all three imports together. 15 minutes for 12 mid-year admissions, including parent app activation.
3. Sister-school onboarding (multi-branch trusts) — your trust opens a new branch with 180 students transferring from the existing school. Export students from the old school's Inkwelly tenant (CSV), tweak the columns to match the new school's class names, import into the new tenant. Half a day for an entire branch onboarding.
4. Aadhaar / APAAR / ABC ID backfill — the NEP 2020 APAAR ID requirement landed mid-year. Your office went out and collected ABC IDs for 1,200 existing students. Without bulk import: open every profile, paste ABC ID, save — 1,200 separate operations. With bulk import: an academic-tab CSV with studentId + abcId columns, dry-run, run. 20 minutes for 1,200 ID backfills.
5. RTE 25% admission compliance (May) — 25 students admitted under RTE need their isRTEStudent flag set to true after EWS certificate verification by the District Education Officer. Profile import with studentId + isRTEStudent: true for the 25 rows. Under 5 minutes for the entire RTE cohort.
Common bulk import scenarios — every Indian school runs these every year
- New session onboarding (March–April) — import the entire admission round in one batch from your office's existing Excel sheet.
- Mid-year transfer-in admissions (any month) — onboard students transferring in from other schools using their Transfer Certificate data.
- Sister-school migration (multi-branch trusts) — move student records from one Inkwelly tenant to another via export → CSV → import.
- Migration from competitor ERPs — Fedena, Entab, SchoolMint, campus-style ERPs, or custom in-house systems all export to CSV. Import lands them in Inkwelly with photos and parent records intact.
- Migration from Excel-only schools — most Tier-2 / Tier-3 schools still run on Excel. Bulk import is the bridge — your office's existing Excel becomes the database in one upload.
- APAAR ID + ABC ID backfill (NEP 2020 compliance) — backfill central-registry identifiers across existing students once your office collects them.
- Aadhaar cleanup audits — your compliance dashboard shows 47 students with missing or malformed Aadhaar numbers; collect via parent campaign, fix in CSV, re-import.
- RTE 25% reservation tagging (May–June) — flag the 25% reserved-category students after District Education Officer EWS verification.
- Multi-address data ingestion — students whose families maintain a permanent address in their home village and a current address near the school hostel.
- Multi-parent data ingestion — both father and mother, plus a guardian uncle, plus a paying-parent grandparent, all linked to the same student.
- Class-by-class onboarding for new branches — each grade's class teacher fills their own CSV; import them tab by tab as each cohort is ready.
- Photo bulk-attachment — your school's photographer delivers 800 ID-card photos as a Google Drive folder with public URLs; CSV with
studentId+profilePhotoUrlruns the attachment in one go. - Annual photo refresh — the next academic year's photos uploaded to a hosting service and bulk-attached via the import.
See bulk CSV import on your school's data, live in 30 minutes
Bring an Excel sheet or CSV from your office — even a messy one. We'll set up your school during the demo, run a real bulk import on your real data, and show you exactly how many minutes the March onboarding will take next year.
Limits, safety, and the small print
File size: 10MB max per CSV. This is sufficient for ~25,000 student profile rows in a single upload — far more than any Indian school admits in a year. If your import is genuinely larger (large multi-branch trust migration), split into two CSVs and run sequentially. Both runs are independent atomic batches with their own results.
Photo size: 5MB max per file. The photo download service validates content-type as image and rejects oversized files with a clear per-row error. Photos that fail download don't block the row — the student profile is still created, just without a photo. Re-import the failing rows after fixing the URL or the photo size.
Required headers per tab. Profiles need studentId, admissionNumber, firstName, dateOfBirth, gender. Addresses need studentId, addressType, addressLine1, city, state, country, postalCode. Parents need studentId, relationshipType, firstName, lastName, mobile. Academics need studentId, classId, rollNumber. Missing required headers stops the import with a clear list of missing columns shown in the Results dialog. Optional columns can be added in any order — Inkwelly matches by header name.
Per-row atomicity. Each row is processed as its own database transaction. Validation failures on one row never block other rows. The 312-of-320 success outcome is the norm — partial-success rows preserve every successfully-applied field; failed rows stay editable in your CSV.
Duplicate detection. studentId, admissionNumber, and aadhaarNumber are unique per organisation. If a CSV row matches an existing student on any of these, the row is rejected with a duplicate error pointing to the colliding field. Existing students are never silently overwritten — to update existing students, use Bulk Update Students, not Bulk Import.
Auto-User creation. Every successfully-imported student profile automatically creates the matching User and UserProfile rows in the same database transaction. The student's parent app login works on day one — no separate user-provisioning step.
Audit log. Every successful import row writes to the school's audit log with the user, timestamp, IP address, and source ('Bulk Import Students'). The audit log is exportable from the school admin panel. If a wrong CSV is uploaded by mistake, the audit log shows exactly which rows landed and you can soft-delete them (90-day restore window in Student Information).
Multi-tenant isolation. Every CSV upload is scoped strictly to your school. Multi-branch trusts run bulk imports per-school independently — no cross-tenant access, no risk of importing into the wrong school's records. The school's session context is auto-attached to every imported row.
Role-based access. Bulk import is gated to school admin and principal roles by default. Class teachers and other staff don't see the import tab in their navigation. Configure per-role permissions from your school's IAM settings.
No Excel format. Inkwelly only accepts CSV (.csv). Excel .xlsx and .xls files are rejected at upload — convert to CSV first (Excel: File → Save As → CSV UTF-8). This is intentional — CSV is plain-text, deterministic, and preserves Indian regional script (Devanagari, Tamil, Telugu, Kannada) when saved as UTF-8 BOM, while Excel format introduces silent encoding bugs that corrupt non-Latin names.
किस मॉड्यूल का हिस्सा
1 moduleअक्सर पूछे गए सवाल
10 सवालWhat CSV format does Inkwelly require?
Plain CSV — `.csv` file with comma-separated values, UTF-8 encoded (UTF-8 BOM is recommended if your CSV contains Devanagari, Tamil, Telugu, Kannada or any non-Latin script). Excel `.xlsx` and `.xls` files are not accepted — Excel introduces silent encoding bugs that corrupt non-English names. Use Excel: File → Save As → CSV UTF-8 to convert. Header row is required and column names must match the downloaded template (header order doesn't matter — Inkwelly matches by name).
How big can the CSV be?
10MB max per file, which fits roughly 25,000 student profile rows. For larger migrations (multi-branch trusts moving 50,000+ students), split into multiple CSVs and run them sequentially — each run is its own atomic batch with its own per-row results. The 10MB limit is on the CSV file itself; downloaded photos are capped separately at 5MB per photo.
Can I dry-run the import before actually creating records?
Yes — the Dry Run checkbox is on every tab. Tick it, click 'Validate Data', and Inkwelly runs the full pipeline (parsing, header check, per-row validation, duplicate detection) without writing a single row. The Results dialog shows valid count, invalid count with specific per-row errors, and processing time. Fix the invalid rows in your CSV, re-validate, and once you're at 0 invalid, untick Dry Run and run for real. The actual import becomes a formality.
What happens when one row fails validation — does the entire import roll back?
No. Each row is processed atomically — success and failure are independent. If 312 of 320 rows are valid and 8 have errors, the 312 are saved and the 8 are reported with specific error messages per row ('Aadhaar must be 12 digits', 'studentId already exists', 'Email format invalid'). A downloadable Error Report CSV lists every failed row with its original data and the validation messages — fix them in your office's working sheet and re-upload only the corrected rows. No all-or-nothing rollback, no churn.
Can the system download student photos from URLs in the CSV?
Yes — for Profile and Parent imports. Add a `profilePhotoUrl` column with public HTTP/HTTPS URLs (max 5MB per photo). The 'Download Photos' checkbox is on by default. Inkwelly downloads each photo, uploads it to your school's media library with a sensible filename, and attaches it to the student/parent profile in the same import run. URLs that fail (404, broken image, oversized) are logged in per-row results — fix and re-import only those rows. Photos appear on student lists, ID cards, and the parent app immediately.
What if a studentId, admissionNumber or Aadhaar already exists in our database?
The row is rejected with a duplicate error pointing to the colliding field — `studentId`, `admissionNumber`, and `aadhaarNumber` are unique per organisation. Existing students are never silently overwritten by a bulk import. To update existing students, use [Bulk Update Students](/features/bulk-update-students) instead — that feature is designed for editing existing records and shows you the previous values before saving.
Does the import handle Indian date formats?
Both DD/MM/YYYY (Indian convention — e.g., 15/03/2010) and YYYY-MM-DD (ISO format — e.g., 2010-03-15) work out of the box. The validator parses each format and normalises to ISO internally. US-style MM/DD/YYYY is intentionally rejected to prevent ambiguous parsing — Aadhaar PDFs, transfer certificates, and Indian state board exports are all in DD/MM/YYYY or YYYY-MM-DD, so this matches what your office actually has.
Can I import addresses and parents in the same upload as profiles?
They're separate tabs — Profiles, Addresses, Parents, Academics — because student data has different cardinality. One student → one profile, but one student → multiple addresses (permanent + current + correspondence), multiple parents/guardians, and per-year academic placements. Run the imports in order: Profiles first (which creates the student records), then Addresses, Parents and Academics (which link to existing students by `studentId`). All four can be done in a single 10-minute session.
Is the parent's data sent to a third-party service during import?
No. CSV parsing runs entirely on Inkwelly's servers in the Mumbai region — your students' Aadhaar, mobile and personal data never leaves India. CSV files are parsed in memory and discarded after the import (we keep only the structured database records, never the raw file). Photo downloads are validated as image content-type and capped at 5MB. Compliant with the DPDP Act 2023.
What happens to existing students if I re-import the same CSV?
Re-importing is safe — the duplicate detection on `studentId`, `admissionNumber`, and `aadhaarNumber` rejects rows that match existing students. Re-uploading the same CSV produces zero new records and a 'duplicate' message on every row. To intentionally update existing students, use [Bulk Update Students](/features/bulk-update-students), which is designed for editing — Bulk Import is for creating only.
आपको ये भी पसंद आ सकता है
2 लेखInkwelly आपके स्कूल पर — खुद देखें
30 मिनट का डेमो। आपके मौजूदा ERP को आपके साथ खोलकर, कॉल पर ही आपका डेटा Inkwelly में लोड करते हैं। कॉल ख़त्म होते-होते एक तय तारीख़ का गो-लाइव प्लान आपके हाथ में।