Access is granted, never inherited: staff logins in a school

A staff record is not a login

The convenient design is for creating an employee to create an account. It is also the design that quietly gives system access to the visiting music teacher, the contractor, the bus attendant and the person who joined last week and starts on Monday.

Keep the two apart. A directory entry says this person works here. A login says this person can open the system, and that should be a separate act somebody performed, on a date, for a reason. When the two are the same event, nobody can answer the only question that matters at audit: who can currently sign in, and who decided that?

Handing over the first password

The moment an account is created is the moment most school systems become insecure, because the first password is usually a pattern: the school's name, the year, or the same default for everyone.

1. Generate it, uniquely, per person. A shared default is a master key that spreads by word of mouth and never expires.
2. Force a change on first sign-in. The temporary password is a handover mechanism, not a credential.
3. Hand it over deliberately. Give it to the person, in a form you are willing to have recorded; do not print a list of them for the staff room noticeboard.
4. Never send credentials through a channel you do not control, and never in the same message as the sign-in link if you can avoid it.
5. Require a second factor. For anyone who can see student data or move money, a password alone is not a boundary — it is a single string that has probably been reused.

Deactivate; do not delete

When a teacher leaves, the instinct is to delete the account and tidy up. Do not. Their name is on marks they entered, invoices they raised, approvals they gave and messages they sent. Deleting the account either orphans that history or, worse, lets it be reassigned.

Deactivate instead: the account can no longer sign in, and every record it touched still names who touched it. If the same person returns next session, reactivating is a decision somebody makes rather than a new identity that fragments their history.

Roles are the floor; record scope is the ceiling

"Teacher" is a role. It is not an answer to the question of which students a teacher may see. In a school of two thousand, a role that grants the whole student directory to everyone teaching a subject is a role that has not been thought about.

• Scope by assignment. A class teacher works with their own class; a subject teacher with the sections they actually teach. Derive that from the timetable and the teaching assignments rather than asking somebody to maintain a second list.
• Separate duties on anything reversible in money. The person who requests a refund, a waiver or a leave approval should not be the person who approves it.
• Make changes take effect now. If a permission change only applies after the next sign-in, then revoking access from somebody at 11 a.m. does not actually revoke it. Resolve permissions per request, not once per session.

How this works in Vidyapeeth360

There is no staff self-signup. An employee record is a record; access is granted explicitly, through one shared path that creates the login, links it to the person's identity, generates a unique random temporary password, marks it must-change, and returns a handover bundle the administrator gives to the individual. Re-granting to somebody who already has a login links the existing account rather than creating a second one.

Sign-in is password plus a one-time code by default, with an authenticator app and single-use backup codes available; wrong-code attempts are capped cumulatively rather than reset by asking for a new code. Permissions are resolved fresh on every request — the session token carries an identity, not a permission list — so a role change or a revocation applies to the next click, not the next login.

Beyond roles, a pure classroom persona is scoped to the class-sections they are actually assigned, derived from the timetable and explicit teaching assignments, so a subject teacher's marks and attendance surfaces stop at their own sections. Separation of duties is enforced on refunds, concessions, leave approvals and payroll — the requester cannot be the approver.

Leavers are deactivated with their history intact, employee codes come from one per-school series, and statutory identifiers are format-checked on the server rather than trusted from the form. The access model, the staff register and the user list are three views of the same decision: who is here, and what may they open.