Chapter 2

Staff Onboarding

school_adminprincipal

Overview

New staff accounts in CampusOS never get created directly by one person acting alone. Instead they go through a maker-checker workflow: one person (the "maker" — typically the School Admin) submits a request, and a different person (the "checker" — typically the Principal) must review and approve it before the account is actually created and login credentials are issued.

Key concepts

Maker-checkerA control pattern, common in finance and school administration, where the person who initiates an action can never also be the one who approves it. It exists to prevent a single compromised or careless account from unilaterally creating staff logins — CampusOS enforces this at the system level, not just as a UI convention (Figure 2.4 below shows the block in action).
Requester (maker)The person who fills in and submits the "Request New User" form.
Approver (checker)A different person — with Principal or School Admin authority — who reviews the pending request and either approves or rejects it.

2.1 Requesting a new user

The Users page with no staff yet, showing the — Figure 2.21. Users — empty, before any staff have been requested.

The blank — Figure 2.22. The Request New User form.

The Request New User form showing validation errors — Figure 2.23. Negative scenario — submitting with required fields missing.

The form filled in to request a Class Teacher account — Figure 2.24. Filled in to request a Class Teacher account for Class 5A.

Confirmation that the staff request was submitted and is pending approval — Figure 2.25. Submitted — the request is now pending Principal approval.

The requests list showing two requests pending approval — Figure 2.26. Two requests now pending approval.

Field reference
Field	Required	Description	Example
`Full Name`	Required	The staff member’s name.	—
`Role`	Required	e.g. Class Teacher, Subject Teacher, Principal, Accountant.	—
`Email / Phone`	Required	Used for the account’s login identity and notifications.	—

2.2 Maker-checker approval

Request submitted

The maker fills in the form and submits — nothing is created yet.

Pending review

The request sits in Approvals until a different person opens it.

Reviewed by a checker

A Principal or Admin — never the same person as the maker — decides.

Approved or rejected

Approved creates the real account with a temp password; rejected creates nothing.

The maker-checker approval flow every staff request goes through.

The Approvals screen showing the requester is blocked from approving their own request — Figure 2.27. The requester cannot approve their own request — the system blocks it, not just a UI convention.

Can this account approve the request currently open?

CampusOS checks the approver's identity against the request's creator on every approval attempt, server-side — not just by hiding the button in the UI.

Access denied

The reviewing account is the same one that submitted the request

The approval is blocked outright, regardless of the reviewer's role.

Access granted

The reviewing account belongs to a different Principal/Admin

The request can be approved or rejected normally.

The Approvals screen as seen by the Principal, showing pending requests — Figure 2.28. A different person (the Principal) reviews the pending requests.

A request being rejected, with a rejection reason — Figure 2.29. Negative scenario — one request rejected with a reason.

A request being approved — Figure 2.30. The other request approved — this creates the real user account.

The Users list now showing the newly approved Class Teacher — Figure 2.31. The new Class Teacher now appears in the Users list.

Validation rules & common errors

Validation rules & common errors
Trigger	Error shown	Resolution
Required field left blank on the request form	Field-level "required" message	Fill in every required field.
The requester tries to approve their own request	You cannot approve your own request	A different Principal/Admin account must review it.
Duplicate email or phone submitted on a second request	This email/phone is already in use	Use a unique email and phone per staff member.

A temporary password is generated automatically

On approval, CampusOS generates a random temporary password for the new account. It is not shown anywhere retrievable afterward — communicate it to the staff member at the moment of approval, or use the password-reset flow if it is lost.