Skip to main content
A role is a named bundle of permissions. You invite a member of staff, give them a role, and that role decides every screen they can open.

​
Inviting someone

1

Add them on User Management

Their name, the email address they will sign in with, and their role.
2

They set their own sign-in

You do not set a password for them. They open the sign-in page, choose First time here? Set up your sign-in, and pick their own.
3

They confirm and sign in

That is what moves them from Pending to Active.
The invitation is the authorisation, not the sign-up. Somebody who creates a sign-in for an address you never invited gets nowhere — there is no staff record to match them to. This is why you should invite the exact address they use.
Full first-time detail, including what to do when the email does not arrive, is in Signing in for the first time.

​
Building roles

Permissions are grouped the way an administrator thinks about them:
Viewing and editing pupil records, viewing and editing staff records, and viewing or marking registers.
Viewing and editing classes, subjects and the calendar; creating tests and entering marks; publishing and withdrawing report cards.
Viewing fees and invoices; editing the fee grid and running billing; recording payments; and separately, approving fee changes, refunds and waivers.
Managing user accounts and roles, editing school branding and reference numbers, and viewing the system log.
The full list of permission keys is in the permissions reference.

​
Roles worth setting up

Most schools end up with something close to this:
Keep approving separate from doing. The point of approve_refunds sitting apart from record_payments is that the person who takes money is not the person who signs off on giving it back — and EduControl enforces that the requester of a refund cannot approve it, whatever their role says.

​
When someone leaves

Deactivate them; do not delete them. Their name stays attached to every payment they took, register they marked and mark they entered, which is what makes those records defensible. An inactive account is refused at sign-in, and can be reactivated if they come back.

​
Who can do this

The manage_users permission.