Right access for every staff member. In two clicks. From day one.

Why a new accountant in your school waits two days to do real work

It is April 1st. Your school's new junior accountant is on her first day. The principal had to email the ERP vendor on March 28 saying 'please add this user'. Two business days later, the vendor replies that the account is ready — but the login they created has access to payroll, salary slips, and TDS statements, none of which she is supposed to see. Worse, the vendor mapped her to the sister school's data by mistake. Another email. Another wait. By Wednesday afternoon she finally gets a working login. The principal sees the over-permissioning and shrugs — either she logs in and works, or the front-desk fee counter stays closed.

This pattern is universal across Indian school ERPs sold in the 2010s. Onboarding a staff member takes two to three days because user creation runs through a vendor's support queue. When the access finally arrives, it is the wrong shape — over-permissioned because the vendor's role list does not match your school's actual structure. So sensitive data leaks daily. Not because anyone is malicious — because the system is too coarse to scope it properly. A salary slip ends up in a parent's inbox. A teacher accidentally cancels another teacher's homework. A class teacher promotes the wrong student. Every incident ends with the same finger-pointing meeting and the same resolution: 'we'll be more careful next time'. Nothing structural ever changes.

Inkwelly rebuilt the assignment layer from scratch. Role Assignments is a self-serve panel inside your school's IAM dashboard. Your principal or office admin assigns roles to staff in two clicks. The change takes effect on the staff member's next login — no vendor support ticket, no wait. And every single change — the role assigned, the role revoked, the role replaced, the admin who did it, the timestamp — is recorded in Audit Logs for inspection day and DPDP audit day.

How role assignment works in your school

Open the IAM dashboard → click Assignments. The panel shows every staff member in your school with their currently assigned roles, employee ID, profile photo, the admin who assigned the role, and the timestamp. Two filters at the top — by name, by role. One button — + Assign Role.

Step 1 — pick the staff member. Type their name or employee number in the searchbox — results filter live across first name, last name, and employee ID. Click the row.

Step 2 — pick one or more roles. A multi-select dropdown lists every active role from your school's role catalogue. Tick Class Teacher. Need this teacher to also handle Sports? Tick Sports In-charge. Save.

Two assignments are now created — one per role — both attributed to your admin user, both timestamped to the second. The staff member's effective permissions are the simple sum of both roles — every action either role allows, they can do, plus nothing else. Permissions only add, never subtract. So the result is predictable: if a teacher has both Class Teacher and Sports In-charge, look at both role definitions, take everything they cover — that is exactly what the teacher can do in your ERP.

When the change takes effect. The assignment is saved instantly. For an existing logged-in session, the new permissions apply within 15 minutes (the next time their login refreshes). For a new joiner who has never logged in, the assignment is in place before they even create their password — they walk in with the right access from the first second. If you ever need to revoke access faster than 15 minutes, deactivate the entire staff account from Employee Management — that locks them out instantly.

Revoking is one icon. Each assignment row has a revoke icon. Click it, confirm. The role is removed. The staff member loses that role's permissions on their next login refresh. The audit log records the revoke with timestamp and admin user.

Atomic role change for promotions. When a Class Teacher is promoted to Vice Principal in October, you do not want them to briefly have both roles, or briefly have neither. Inkwelly's Replace Roles operation does the swap atomically — the old role and the new role change in one save. Either the whole change applies or nothing changes. No half-state where the staff member is locked out for thirty seconds while two screens are doing different things.

Multi-role staff — the realistic Indian school pattern

Most school ERPs assume one role per staff member. Real Indian schools do not work that way. Your Maths teacher is also the Class Teacher of grade 8B and runs the Computer Lab on Wednesdays. Your English teacher is also the House Master of Mehta House. Your PE teacher is also the Sports Coordinator. Your librarian also handles the Front Desk on Saturdays. Every school has people who wear two or three hats — your ERP needs to reflect that without forcing your principal to share logins or create duplicate accounts.

Inkwelly assigns multiple roles to a single staff member in one save. The role dropdown is multi-select. Tick Subject Teacher + House Master for one teacher; tick Class Teacher + Computer Teacher for another. Their permissions add up — every action either role allows, they can do. Two roles, one login, one audit trail, one staff record. The same teacher, the same Inkwelly account, the right permissions for each part of their job — with no risk of accidentally promoting a student because they happen to have a forgotten side-role with edit access.

Atomic role swap — promotion without a lockout

A Class Teacher is promoted to Vice Principal in October. The naive way to handle this is two steps: revoke the old role, then assign the new. But between the two steps, the teacher briefly has neither role — if they refresh their dashboard at the wrong moment, they are locked out of everything. If the second step fails for any reason, they are stuck with no access until someone notices.

Inkwelly does the swap as a single, all-or-nothing change. Inside one save, every old role is removed and every new role is added. Either the whole change applies or nothing changes — there is no in-between state visible to the teacher's session. If the save fails for any reason, the original assignments stay intact. The teacher is never half-promoted or half-locked-out. This is the standard a serious ERP should meet — not a luxury. Your staff trust the system because the system never leaves them stranded mid-change.

Effective permissions — at a glance, exportable

Open any staff member's assignment detail and Inkwelly shows their full permission list, computed live. It is the sum of every active role they hold. If Class Teacher covers 37 actions and Sports In-charge covers 9 with 4 overlapping, you see 42 permissions in total. The list is grouped by area — Students, Attendance, Fees, Examinations, Transport, Library — the same way the Role Builder lays out permissions, so reviewing what someone can do uses the same mental model as designing a role.

Download the list as CSV when an auditor asks 'show me exactly what Priya Sharma can do in your ERP'. The export carries her employee ID, the roles she holds, the full permission list, and the export timestamp. Combined with the audit trail of every assignment change, this is the precise packet your school hands an inspector or trustee — without spending three days assembling it.

Every change is recorded — for inspection day, every day

Every assignment change is written to the Audit Log with the admin who made it, the staff member it affected, the role, the action (assigned, replaced, revoked), the timestamp to the second, and the originating device. This is the trail that turns 'who gave that teacher payroll access?' from a multi-day investigation into a five-second filter on the audit log.

The audit trail cannot be edited or deleted by anyone — not the principal, not the trust admin, not Inkwelly support. That is the point. If a CBSE inspector or a DPDP Act auditor asks for every access change in the last 90 days, the export is one click. If a parent escalates an incident where a teacher had access they shouldn't have, you can pinpoint exactly when the role was assigned, by whom, and when it was revoked. Access governance stops being a policy on paper and becomes a live, queryable record.

Suspending vs offboarding — the right tool for the right moment

When a staff member is suspended pending enquiry, you do not want to revoke their roles permanently. If the enquiry clears them, you want their access restored exactly as it was, with full history intact. Inkwelly handles this with an active / inactive toggle on each assignment. Switch it off — the staff member loses the role's permissions immediately, but the assignment row stays in the database with full timestamp history. Switch it back on — the role's permissions return, no re-tick, no re-assignment, no audit trail break.

Only delete the assignment when the staff member has truly left — resigned, terminated, retired — and the access change is permanent. The deletion still appears in the audit log so the history is preserved, but the assignment is gone from the live list. For schools that need to track ex-staff access history for compliance, the toggle is the recommended pattern. Deletion is for true offboarding. Both are one click in the assignments panel.

Real-world assignment scenarios from production schools

Five routine assignment patterns Inkwelly schools handle every week:

1. New academic session staffing on April 1. Six new joiners, four leavers, three internal promotions. Your principal opens IAM Assignments at 9 a.m., runs through the changes — six assigns, four revokes, three replaces — and the entire school's access map is current by 9:20 a.m. New joiners walk in to a working ERP. Leavers' access is gone before they pack their desks. Promoted staff see their new dashboards on first login.

2. Maternity leave coverage. The Class 7B teacher goes on three months' leave; another teacher covers her class. The substitute gets the Class Teacher role added to her existing Subject Teacher assignment — so she can mark attendance for 7B without losing her math teaching access. Three months later, revoke the Class Teacher from the substitute, audit log shows the temporary grant. Original teacher returns, role is reinstated for her, audit log shows the resumption. Clean, traceable, no shared logins anywhere.

3. Acting Principal during board meetings. The Vice Principal becomes Acting Principal for two weeks while the Principal attends a CBSE board meeting in Delhi. Replace the Vice Principal's role — Vice Principal swapped for Principal. Two weeks later, swap back. Both changes atomic, both timestamped, both reversible without confusion.

4. Suspension during enquiry. A teacher is suspended pending an enquiry into a parent complaint. Mark their assignment inactive — their dashboard immediately stops showing their classes, fees, or homework permissions. They cannot do further damage during the enquiry. Two weeks later the enquiry clears them; toggle back to active; full access restored without re-doing anything.

5. Sister-school transfer. A teacher is transferred from School A to School B in the same trust. Revoke all assignments at School A. Create new assignments at School B using School B's own role list. Same staff record, two different school access scopes, completely independent audit trails. Each school stays in control of its own access map.

See assignment workflow live on your school's staff list

30-minute walkthrough — bring your school's actual staff list. We will assign five of your most critical roles together, on your real Inkwelly setup.

Limits, safety, and the small print

Permissions only add across multiple roles. When a staff member holds two roles, their effective permissions are the simple sum — every action either role allows, they can do. Inkwelly does not subtract permissions through another role. If you want a staff member to NOT have a permission, simply do not assign a role that grants it. This is a deliberate choice — subtractive permission models are notoriously hard to audit, and lead to surprises during inspection week.

Idempotent assignment. Assigning the same role to the same staff member twice is silently skipped — no error, no duplicate, no double permissions. The screen tells you what changed and what it skipped, so the operator sees the actual effect.

Cross-school assignment is blocked. A role from School A cannot be assigned to a teacher at School B — each school's role list is fully isolated. There is no UI path to even see another school's roles. Multi-school trusts run their assignments per-school independently.

A role must be active to be assignable. A deactivated role cannot be assigned to new staff. Existing assignments to a deactivated role still work for the assigned staff, but no new assignments are accepted. To make the role assignable again, reactivate it from the Role Builder.

Soft-deleted staff cannot be assigned roles. A staff member who has left the school is excluded from the assignment dropdowns. Re-activate the staff profile first if they are returning.

Effect timing. Permissions refresh on every login refresh — typically every 15 minutes. For a new login, the assignment applies immediately. For an existing session, within 15 minutes. For an emergency revoke faster than 15 minutes, deactivate the entire staff account from Employee Information — that invalidates all sessions instantly.

The replace operation is all-or-nothing. When you swap an employee's roles, either the whole change saves or nothing changes. If your network drops mid-save, the staff member's access is unchanged, not broken. They are never stuck in a half-promoted, half-locked-out state.

The audit log is immutable. Past assignment events cannot be edited or deleted by anyone — not the principal, not the trust admin, not Inkwelly support. The audit log's value is its tamper-resistance. Every change is appended; nothing is rewritten.