SCHOOL OPERATIONS · ACCESS LIFECYCLE
School ERP User Offboarding: What to Do When Staff Roles Change or People Leave
A responsible access lifecycle for school staff transfers, temporary cover, departure, record ownership and handover.
Conceptual product view · no customer records or performance figures
THE SHORT ANSWER
When staff change roles or leave, promptly review their account, permissions, active work and hand-off responsibilities. Revoke or adjust access through an authorised process, preserve records that the institution needs and reassign unresolved tasks to a current owner. Do not use a shared login to keep work moving; verify how the product handles account deactivation and history.
01 / TRIGGER & OWNER
Define who notifies the system owner when a role changes.
Offboarding often fails because the person who knows an employee has left is not the person who manages software accounts. Establish a hand-off from the school’s authorised HR or leadership process to the system administrator. Include transfers, temporary cover and long leave—not only final departure.
Name the reviewer and expected timing under school policy. Keep a record of the trigger and the individual account involved. Do not circulate sensitive employment information more broadly than necessary.
02 / CURRENT ACCESS
Reconcile the person’s active accounts and permissions.
Identify each account and role associated with the staff member. Determine which access should end, which permissions need adjustment and whether a temporary assignment has an explicit end date. Review print and export access as well as menus and on-screen records.
Confirm account deactivation and session behavior with the product. Do not assume that removing a role immediately invalidates every active session unless that behavior is verified. Use the school’s approved credential and incident procedures.
03 / RECORD OWNERSHIP
Hand over open work without transferring another person’s credentials.
List pending admissions, fee questions, attendance corrections, academic tasks or reports that need a new owner. Reassign responsibility through the institution’s process so the next staff member has appropriate access and context.
Do not keep a former employee’s shared password active as a shortcut. Where a record or task is personally associated with a user, ask the provider how ownership should be reassigned without obscuring history.
04 / DATA & DEVICES
Protect information held outside the ERP during the departure.
School work may exist in exported reports, printed lists, email attachments or personal devices. Follow school policy for returning or deleting copies and securing devices. Limit the offboarding checklist to information the institution is authorised to manage.
Review shared folders, saved credentials and any approved integration or notification accounts through the responsible administrator. Do not assume the ERP can revoke copies already exported or erase information from an unmanaged device.
05 / HISTORY & RETENTION
Preserve institutional records while ending unnecessary access.
The school may need to retain the employee’s operational history for continuity or review. Confirm which actions the system records, how they remain attributable after deactivation and who can access that history. Do not delete a user or record if it would remove context the institution must preserve.
Follow applicable retention policy and professional advice. A user activity log does not alone establish a full investigation record or statutory compliance. Document the offboarding decision and the date access was changed.
06 / VERIFY COMPLETION
Close the loop with a second check and update the access register.
After changes, confirm the account cannot perform tasks outside its new role and that the hand-off recipient can access assigned work. Record any product limitation or unresolved session question and escalate it to the provider or security owner.
Update the active-user register and review it periodically. A consistent lifecycle protects staff privacy and school records while helping the next administrator understand who is responsible for each task.
A FIELD GUIDE FOR YOUR TEAM
A staff access-change checklist
Use this for role transfer, temporary cover, leave and departure. Adapt timing to school policy and the person’s actual responsibilities.
| Lens | Question to ask | What to record |
|---|---|---|
| TRIGGER & OWNER | Define who notifies the system owner when a role changes. | A defined notification path and responsible account reviewer. |
| CURRENT ACCESS | Reconcile the person’s active accounts and permissions. | An account and permission inventory with a verified disable process. |
| RECORD OWNERSHIP | Hand over open work without transferring another person’s credentials. | A work hand-off with new owners and role-appropriate access. |
| DATA & DEVICES | Protect information held outside the ERP during the departure. | A controlled review of school data copies and approved credentials. |
| HISTORY & RETENTION | Preserve institutional records while ending unnecessary access. | A dated access change and confirmed history/retention approach. |
| VERIFY COMPLETION | Close the loop with a second check and update the access register. | A completion check, updated user register and assigned open issues. |
CODEPEX IN CONTEXT
Useful guidance begins with clear scope.
School ERP declares user roles and permissions and administrative activity history. Exact account deactivation, session revocation, ownership transfer and retained audit detail must be confirmed. This page does not claim automated HR-triggered offboarding.
Product-specific statements are based on the current owner-controlled capability declaration. Ask CodePex to confirm any institution-specific configuration or unlisted requirement.