Deleted by mistake? Restore them in one click.

Why every Indian school office needs a Trash bin

The morning of April 3rd, 2026. Promotion week. The office assistant in a Bahraich-based CBSE school is cleaning up the previous session's student list — marking transferred students inactive, deleting test entries created during admission practice runs, deactivating students whose families moved cities. She is fast, she is tired, and she is doing this between fee receipts and parent phone calls. At 11:47 AM, she clicks delete on the wrong row. A real student. Class 7 B. Admission number STD-2024-0142. Gone from the active list.

In most Indian school ERPs, that mistake means a 3-hour recovery operation — pulling the previous-session backup from the IT vendor's email, reading SQL out to the support engineer, paying ₹2,000 for a database restore, hoping nothing else got affected. Or worse, no backup, no recovery, and the office quietly recreates the student from the parent's admission slip — losing the original admission date, the receipts trail, the TC history.

We built Student Trash for this exact moment. Every student you delete moves to Trash — a soft-delete bin that holds the full record, the photo, the parent details, the fee history, the audit trail. One click to restore. The student reappears in the active list with everything intact — including the original admission number. No SQL, no support ticket, no panic.

How Student Trash works

When anyone with delete permission removes a student from the active list, the record is soft-deleted — moved to Trash with a deletedAt timestamp, the deletion reason captured at the time of delete, and the user who performed the action recorded in the audit log. The active student list no longer shows the row. Reports, attendance, fee dues, and exam dashboards stop counting them. From every other angle the student looks gone.

But the record is preserved in full. Open /students/trash from the Student Information sidebar. The view loads up to 100 deleted students at a time, sorted by deletion date with the most recently deleted first. Each row shows the full name (in your school's primary language), admission number, last class with grade level, profile photo, the date they were deleted, and the deletion reason your staff entered. A search box on top lets you find by name or admission number across all pages of trashed records.

Two actions per row: Restore and Delete permanently. Restore opens a small dialog asking for optional audit remarks — type why you are restoring (e.g., 'Wrongly deleted, parent confirmed admission is active') and click Restore. The student reappears in the active list with the original admission number, fee history, attendance trail, and parent links intact. Delete permanently opens a different dialog — it asks you to type the student's full name to confirm, and only enables the destructive button after the typed name matches exactly. The student is then removed forever — that record cannot be recovered.

Walkthrough — three screens, end to end

“April mein promotion ke time ek student ko galti se delete kar diya tha — Class 6 B ka. Pehle aise haalat mein support ko phone karte the, 2-3 ghante ka kaam tha. Ab Trash khola, naam search kiya, Restore kiya — 30 second mein wapas active list mein aa gaya, fee receipts bhi sab safe। Office staff ka pressure 90 percent kam ho gaya।”

Real-world office routines this turns into 30-second tasks

Five routine school office mistakes that traditionally cost hours of recovery work:

1. Wrong-row delete during April promotion cleanup. Office is marking 30 transferred students inactive after the session ends. One real, currently-enrolled student gets clicked instead. Without Trash: 3-hour database restore, ₹2,000 vendor charge, anxiety for the parent. With Trash: open Trash, search the admission number, click Restore. Under 30 seconds.

2. Test admission entries created during demo. A new IT vendor or a Inkwelly trial week generates 5-8 fake students with names like 'Test Student' or 'ABC Demo'. After the trial, these need permanent removal. Without Trash with confirmation: someone deletes them but accidentally also deletes a real student named 'Test Aman'. With Trash: bulk-trash the test entries, then permanent-delete each one with typed-name confirmation. Zero risk to real records.

3. TC issued in error. A class teacher requests TC for a student whose family was supposed to leave but changed their mind at the last moment. The student was already marked left and deleted. Without Trash: re-create the student from scratch, lose admission date, lose receipts, parent complains about new admission number. With Trash: restore from Trash. Admission number preserved, fee history intact, TC withdrawn cleanly.

4. Bulk delete by mistake during data cleanup. A school admin runs a bulk operation to deactivate students from a previous session and selects the wrong filter. 40 active Class 8 students get deleted in one click. Without Trash: panic, escalate to vendor, hours lost. With Trash: open the Trash list, sort by today, click 'Restore' on each — or run a bulk-restore script via the support team. All 40 students back in the active list within 5 minutes, no data lost.

5. Parent invokes DPDP right-to-erasure. A parent who has withdrawn their child requests permanent deletion under the DPDP Act 2023. Without a controlled permanent-delete: the office runs raw SQL, with all the risk that implies. With Trash: open Trash, find the student, type-name-confirm permanent delete. The parent gets a documented, auditable confirmation; the school stays compliant.

See Student Trash live in 30 minutes

Bring 3 routine deletion mistakes you have made (or are afraid of making). We'll set up your school's classes during the demo, run the workflows live with your real data, and show how each becomes a one-click restore.

Limits, safety and the small print

Soft-delete is the default. Every delete from the active student list moves the record to Trash. There is no way to bypass Trash and permanently delete in one step from the active list — that path simply does not exist. The only route to permanent removal is via Trash → typed-name confirmation. This is intentional and not configurable: the cost of an irrecoverable wrong-click is too high to allow any shortcut.

Up to 100 trashed students per page. Larger schools accumulating thousands of trashed records page through with previous/next controls. Search filters across all pages, so a 4,000-student trash is still navigable in one query. Sort defaults to most recently deleted first.

Restoration preserves admission number. When a student is restored, the original admission number, registration number, admission date, fee receipts, attendance records, and parent links return as they were. The student is not 're-admitted' — they are restored. Reports run against past sessions stay correct.

Permanent delete is irreversible. Once you typed-name-confirm permanent delete, the student record is removed from the database. The audit log entry survives — it remembers that the deletion happened, who did it, when, and the original admission number — but the personal data is gone. There is no recovery path. We do not keep a hidden 'super-trash'.

Role-based access. By default, only school admin and principal roles see Trash and have permission to restore or permanent-delete. Class teachers and other staff see only the active student list with delete permission gated to their assigned section, and their deletes go to Trash where only authorised roles can act on them. Configure exact permissions per role from the Identity & Access Management settings.

Multi-tenant isolation. Like every Inkwelly module, Trash operates strictly within your school. Multi-school trusts run independent Trash views per school — there is no cross-tenant access. A trashed student in School A is invisible to School B's office, even within the same organisation.

Backups still apply. Soft-delete is your day-to-day safety net. Inkwelly's nightly database backup is your disaster recovery layer underneath. If you have permanently deleted something and discover the mistake within the backup window, support can restore from backup — but the typed-name confirmation flow exists precisely so this is rarely needed.