Separation of duties

Some actions in EduPrefect cannot be completed by one person, however senior they are. One member of staff requests the action; a different one approves it. Only then does anything happen.

This is not a permission being withheld. The person requesting genuinely holds the right to do it — the second signature is a separate requirement on top.

Why

Every control in a school system has to survive the same awkward question: what if the person holding the permission is the problem? Not necessarily dishonest — tired, rushed, or working from a convincing phone call.

A single permission check cannot answer that, because the attacker and the authorised user are the same account. Requiring two distinct people changes what a compromised or careless account is worth: on its own, it is not enough.

The cost is real — an approval is a second person interrupted — so it is applied narrowly, to actions that move money outward or change where money lands.

What is gated

Refunds and reversals. Money going back out to a payer. One person records the request, with the reason and the amount; a second approves it. The request itself is fixed once made — the amount, the payment and the reason cannot be edited after the fact, so the trail cannot be rewritten to look like something that was approved.

Both the request and the approval need the same permission, Reverse a wrongly-recorded payment. In a standard set-up that is the bursar and the proprietor — and any custom role your school creates that includes it, provided that person also holds one of the built-in admin roles. So in a school with one bursar, the second person is usually the proprietor.

Expect to type your password again. Raising a refund asks for it, and so does approving any money-out request. (Requesting a reversal does not — the approval on the other end still does.) Being already signed in is not the same as being present, and a phone left unlocked on a desk should not be able to send money out.

Changing the school’s settlement account. Where every future fee payment lands. Historically the smaller action was gated and the larger one was not: a single permission holder could redirect all future settlements. Both now cost the same.

This one is approved by a different permission, Manage integrations, held by the school IT administrator and the proprietor. That is deliberate: the person who runs the school’s money is not the person who signs off on where it lands.

Approving an account change asks for a password too, for the same reason.

When the second person reviews an account change, they see the resolved bank account name — the name the money would actually go to, fetched at the time of the request. Reading a nine-digit account number back is not a check anybody performs reliably; reading a name is.

You cannot approve your own request

The account that requested an action can never approve it. On the money-out queue it is not offered either — the Approve button on your own request is greyed out, and says why. Reaching the endpoint another way returns a plain refusal, not a silent no-op.

That rule is enforced in more than one place on purpose: once in the service that handles the request, and again in the record itself as a last line of defence. Duplication here is deliberate — a single check is one refactor away from being gone.

Nor can two people approve the same request. Approval claims the request under a database lock, so a double-tap or two administrators acting at the same moment cannot execute it twice.

What happens when approval fails

An approval is not the end of the story — the action still has to run, and it can fail after a valid approval. EduPrefect keeps those two outcomes apart:

• Refused. A business rule said no: the payment was already reversed, or the provider rejected the refund. This is final, and the reason is recorded.
• Did not complete. Something transient went wrong — a timeout, a crash between approving and executing. This needs a person to look at it, so it is raised in the daily exceptions report, and the action can be requested again.

Collapsing those two into “failed” would hide the second kind, which is the kind that strands money.

What this means for you

If you are a bursar: expect refunds and account changes to take two steps and two people. Requesting one is not the same as doing it. Nothing moves until a colleague approves. You can approve another bursar’s refund request, but not your own, and not an account change — that one is not yours to sign off.

If you are the proprietor: you are the second person for both, and in a small school you are the only one available for either. The approval screen exists so you can check the amount, the reason, and — for an account change — the name on the destination account before agreeing.

If you are the school IT administrator: account changes come to you as well as to the proprietor. Refunds do not.

If you are a principal or head teacher: neither approval is yours, by design. Being the most senior person in the building does not make you the second signature on money — that is the whole point of the control. If your school wants you in one of these loops, ask your IT administrator to give you the matching role; seniority alone will not do it.

If you are a parent: this is why a refund is not instant. Your school has to have two people agree to it.