Migration Requests in AceDraft for Teams

Approve is one click, and there is no second click that puts it back. It rewrites the student's sign-in email, changes what kind of account they hold, and switches off their batch seat. Nothing here reverses that. 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

Admin only, and scoped to your organisation at both ends of the call.
With no live batch behind the student, the migration completes itself and never reaches your queue.
Approve moves the account across and empties the seat. Reject writes a status and a note, and changes nothing else.
Limitation: no undo, no bulk action, no search, ten rows a page.
Limitation: nothing stops a rejected student filing the same request again a minute later.

Prerequisites. An admin account with an organisation on the session, and a student who has asked. You cannot start a migration here, only answer one.

Who can open Migration Requests?

Enterprise admins. The route lists that one role, and the guard sends anyone else to a page their role can see: a student to their own resumes, a moderator to the dashboard. Both endpoints behind the page repeat the check and answer a non-admin with "Forbidden: insufficient role for this action".

Scope comes from your session, not the URL. The list filters on your organisation id, and deciding another organisation's request is refused outright.

Where the request comes from before you see it

The student's own Settings page, under the heading Migrate to Personal Account. One email box, one Request Migration button.

Four things stop that button before a row ever exists. An address that is not a valid Gmail, refused with "A valid gmail is required." An active suspension. An email already sitting on another account, refused with "That email is already associated with another account." A session carrying no organisation, which tells the student to sign out and back in.

Past those, the server asks one question: does this student still belong to a batch that hasn't expired? If no, it performs the migration on the spot and files the record as already decided, and the student reads "Migration approved automatically." If yes, it files a pending row, sends an email to your organisation's admin address with a link to this page, and the student reads "Request submitted".

Those settled rows still land in your list: a log, not a queue.

Reading the list

Rows arrive newest first, ten to a page, filtered to Pending until you change the dropdown. The other options are Approved, Rejected, Auto_approved and All statuses. Yes, the fourth keeps its underscore on screen. I never tidied it.

Each row shows the student's name, or their current account email, or a bare user number, in that order of preference, with the requested address and a status pill beside it. Clicking a row opens it and closes any other. Inside sit the current account email, the time it was requested, and the decision time and note once there is one.

While the page loads you get "Loading…". With nothing to show, a dashed box reads "No pending migration requests.", and under All statuses the word simply drops out of that sentence. If the call fails you get "Could not load migration requests." and an empty list, so a broken load and a quiet queue look almost identical.

What Approve does to the account

The server re-runs two guards first, because time has passed since the student asked. A suspension that started in between blocks approval. So does the requested address turning up on another account, with "That email is now associated with another account".

Then it writes. The account role becomes the consumer one the student requested, the account email becomes the requested address, sign-in switches to Google, and the stored password is cleared. Every batch seat that student holds is set to disabled. The request is stamped approved with your id, the time, and your note.

Their resumes are untouched. Resumes hang off the internal user id, which does not change, so the work follows them across.

Two notices follow, both in chat rather than email: one in your thread with the student, carrying your note, and one in their batch's group thread saying a student has migrated and left. Neither can fail the migration.

Reject writes a status, and stops

The row is marked rejected with your id, the time, and the optional note from the box above the buttons. The student gets a chat message saying so, with your note appended. Their account, their role, their email and their seat are all exactly as they were.

There is no cooling-off period in the code. A student who reads that message can open Settings and submit the same address again straight away, and it will land back in your Pending filter.

Both buttons only render on pending rows, both read "Working…" while a decision is in flight, and the server answers a second decision on an already-decided row with "Request already approved." or its equivalent.

Use it, or skip it

Open it when a student is leaving and you want their history to leave with them. Skip it when you were hoping to move an account back, or to migrate a batch in one go, because this page does one student at a time and only ever forwards.

Migration Requests in AceDraft for Teams: Moving a Student to a Personal Account