Review Requests: Assign a Moderator

The temporary password for a new moderator appears on screen once. Close the page before you copy it and nothing on this page will show it again. I'd rather put that in the first line than let you meet it the hard way. I haven't watched this page run. I read its code on 19 September 2026, and everything below is what the code says.

Key takeaways

The page is titled Review requests, and only an enterprise admin can open it.
Two things live here: a moderator list with an add form, and a table of every review request in your organisation.
Assigning writes a moderator's name onto a request and hands them access to that student's chat thread.
Limitation: the table asks the server for the first 100 rows and has no paging control, so row 101 is unreachable from here.
Limitation: reassigning a request adds the new moderator to the student's thread without taking the old one out.

Prerequisites. An admin account and an organisation already created. Try to add a moderator before the organisation exists and the backend answers "Create your organisation first."

Who can open the review requests page?

Enterprise admins, and nobody else. The route carries an admin-only role list, and the guard sends a moderator who types the URL back to the dashboard. The endpoint behind it is role-aware too: an admin sees every request in the organisation, a moderator sees only the ones assigned to them.

How do I add a moderator?

Two fields, then one button. Email has to look like an email and the name needs at least two characters. Fail either and the field turns red with a line underneath saying what's wrong, while the button warns you instead of sending anything. It reads "Adding…" while the request is in flight.

On success the backend makes a fresh account with the moderator role, links it to your organisation, and emails that person a sign-in link with the same temporary password you're looking at. The on-screen note tells them to change it through Forgot password. The count in the Moderators heading goes up.

An email that already belongs to any account is refused with "A user with this email already exists." So this form creates moderators. It cannot promote someone who is already in the system, and there's no remove button here either.

What is in the requests table?

Six columns. Student shows the name above the email, with a dash where no name was stored. Resume is the internal id with a hash in front of it, not a title. Status is one word in a pill: green when it reads answered, amber for anything else. Assigned holds the moderator's name or a dash. Then the assign control, and a View link into the review page for that request.

Rows come back newest first. Before they arrive you get "Loading requests…", and an organisation with nothing waiting gets "No review requests yet." rather than an empty grid.

Resume ids are the thing I'd flag. Honest, and useless at a glance, so the student column is what you'll read to tell two rows apart.

How do I assign a moderator to a request?

Pick a name in that row's dropdown, then press Assign. The dropdown opens on "Choose…" and lists every moderator in your organisation, showing the name and falling back to the email when there isn't one. Press Assign without choosing and a toast tells you to pick a moderator first; nothing leaves the browser. Offline, the action stops there too.

The server checks that both the moderator and the request belong to your organisation, and refuses with a plain message when either fails. When it works, you get a confirmation toast and the table reloads, so the Assigned column fills in on its own.

What does Assign actually change?

Two things. It stamps the moderator onto the request, and it gives that moderator a real seat in the student's direct chat thread, creating the thread if one doesn't exist yet. The seat is a stored row, not something worked out on the fly, which is why the moderator can open the review page and reply rather than hitting a wall.

Status is not one of those two things. Assigning leaves a pending request pending. It moves when the review is answered, elsewhere.

The chat access is additive and idempotent, so assigning the same person twice is harmless. Handing the request to someone new is the case to think about: the first moderator keeps their seat in that thread. If that matters for a student's privacy, the assignment to make carefully is the first one, not the correction.

Who this page is for

Use it as the admin doing traffic control: something came in, someone needs to look at it, and you're deciding who. Skip it if you want to read or answer a request yourself, because that work happens on the review page behind the View link, and moderators reach their own queue without coming through here.

Review Requests in AceDraft for Teams: Reading the Queue and Assigning a Moderator