Staff accounts and access

Two screens do most of this work: Admin → Staff, where an account is administered, and Admin → Access requests, where somebody who has signed in but holds nothing yet is waiting for you.

Access requests

Somebody signs in through your provider, Ten Points establishes that they are who they say they are, and then finds they hold no role at your school. They land on a screen offering to ask, and the ask lands here.

Each request shows when it was requested, the address the provider gave, and whether that address is on your roster. A request from an address that is not on the roster is not automatically wrong – a new member of staff often reaches Ten Points before the MIS catches up – but it is the one worth a second look.

You pick the role. Nothing is granted by signing in.

What a role is, and is not

A role is held at one school. Somebody who works across a trust holds several, one per school, and what they may do can differ at each. There is no wildcard and no trust-level key that opens all of them.

A role is not a login. One login can be a teacher at one school and a parent at another. Do not assume one of each.

Permissions are per capability, and scoped. Awarding points might reach the whole school while reversing one reaches only a year group. That is why two people who both call themselves “an admin” can see different screens.

Administering an account

Admin → Staff shows account status, the account owner, and the address in MIS – which is the address invitations go to, and the reason a member of staff with no address in the MIS shows up in the sync’s notes.

At the bottom is a danger zone, and the screen says what deactivation does before you can do it, because deactivation cannot be undone. Read that panel rather than this page: it is the authoritative description of what happens.

When somebody leaves

End their role. This is the thing to do on the day, and it is the thing that stops them reaching your school’s data. Do it even if the MIS will catch up overnight, because overnight is a long time.

The sync will archive them. Once they are off the MIS roster, the nightly run does the rest.

What they did stays on the record. Every change carries the person who made it, and that does not change when they leave. A school has to be able to answer who changed this, and when, and the answer cannot depend on whether the person still works there.

Their login is not yours to delete. A login belongs to a person, not to a school – they may hold a role at another school tomorrow. What you control is the role at your school.

Somebody acting on another person’s behalf

Where a member of staff does something on behalf of a colleague, the record carries both: who actually did it, and who it was done for. You do not have to do anything to make this happen, and you cannot turn it off.

Who can do all this

Each of these screens is guarded separately. If you can see Access requests but not Staff, that is the intended shape of your role rather than a fault – the Admin index draws the cards you hold and redirects anybody who holds none.