A Student's Path Through AceDraft for Teams: From CSV Import to a Reviewed Resume

A student presses Request review, a row gets written, and that is as far as it travels on its own. No rota, no alert to a moderator. An admin has to open the requests table and put a name on it, and until somebody does, the student's screen reads Requested and looks exactly as it would if a moderator were reading it. That hand-off is your job.

Below are six stages stitched into one route, each linking to the post that covers it. I read those posts and the code they cite on 20 September 2026 rather than running a batch of students through end to end, so take it as a map, not a stopwatch.

Key takeaways

Students never sign up. An admin imports them from a CSV and each is emailed a single-use sign-in link.
One open review request per resume. The next is refused until a moderator marks the last answered.
Written feedback lives in chat, never on the resume list.
Limitation: an admin sits between every student and every moderator, by hand.
Limitation: an export spends a batch credit, then the organisation's wallet, and the student sees neither.

Prerequisites. On your side, an admin account, an organisation and a batch with seats. On the student's side, an email address they will open.

What are the six stages for a student in AceDraft for Teams?

Import, sign in, build, request a review, export, leave. The student drives four. You drive the first and the assignment inside the fourth.

Stage 1: You import the student

Paste or upload rows of email,name and press Import users. Adding students with a CSV covers the seat counter, the skipped rows and the conflict list.

Each new person gets the batch's free credits and a single-use link that signs them in without a password. It is emailed to them and printed beside their address on your screen, so treat that list like passwords.

Stage 2: The student signs in and lands on their resume list

Sign-in sends a student to My Resumes and everyone else to the dashboard. The student's resume list goes through the tiles and every column.

Warn them about that screen. Resumes are identified by an internal id with a hash in front, there is no search box, and the list stops at the 50 newest rows. A failed load and an empty account print the same sentence.

Their side menu holds three entries: My Resumes, Chat, Settings.

Stage 3: Building the resume

+ Create a resume opens a blank editor and Edit on a row opens a saved one. Students writing a campus placement resume get the same component the public site runs, and what changes on the enterprise route lists the differences.

Save writes a draft row against the email on their session, then loads the enterprise export page. That draft row is why an unfinished resume appears in the list at all.

The guard checking whether the batch is still live fails open. If its check errors, the student reaches the editor anyway and the server refuses the save. I wrote it that way deliberately.

Stage 4: How to get your resume reviewed

Request review on a row files a pending request for your organisation. Before it writes, the server refuses an expired batch, a resume belonging to someone else, and a second request on a resume that already has one open. Those checks sit in the backend messages route, read on 20 September 2026.

Then it waits for you. The review requests page is admin-only at the route and at the endpoint. Assigning stamps a moderator onto the request and writes them a stored seat in the student's chat thread; the status stays pending. No moderator can take that job off you, because their queue only returns rows carrying their own id.

From there, Review opens the verify page, where the resume appears as an editable form beside a live preview. Saving writes over the student's own record in place, with no second copy and no version list. The server touches only content columns, so a reviewer cannot move their draft or published state.

Mark answered flips one column and sends the student no text, because the conversation runs through chat. It is also the release: a review answered in chat and never marked keeps that student locked out of asking again on that resume.

Stage 5: The export, and who pays for it

Download on a row publishes the resume, then the server takes a batch free credit if one is left and charges your organisation's wallet if none is. Credit, wallet, refusal walks the gate.

The student is never shown a price, and never a reason when it fails: five server outcomes come back as one apologetic sentence, with the real cause emailed to the admin.

Stage 6: Leaving with the work

In Settings, and only for a student role, sits a Migrate to Personal Account card. With no live batch behind them the migration runs on the spot; with a live batch it files a pending row, emails you, and drops a note in their chat thread. The settings post and the migration requests post cover the two halves.

This is the claim people ask about, so I read the migration executor in the code. Approval updates one user row: the role becomes a consumer one, the email becomes the address they typed, any stored password is cleared, and every batch seat is disabled. Resumes hang off the internal user id, which the migration does not touch, so the work leaves with the person. Approve has no undo.

What this doesn't do yet

You might expect	What's actually there
The student to be told a moderator has it	Nothing renders it. The assignment shows on your table and the moderator's queue only.
Reassigning to remove the first moderator from the thread	It doesn't. Chat seats are additive, so the first assignment is the one worth thinking about.
The ATS scan to sit inside the journey	The enterprise scan route exists, but no menu entry points at it and the report is stored with no owner.

Author's take

The decision I would defend to any placement officer is the one in stage 6. A student's resumes were never owned by the batch, so a college can hand the work back without exporting anything.

The quiet in stage 4 I would not defend. Every screen in that chain is honest with whoever is looking at it, and none of them faces the student who asked.

Use this if you have an admin who will open the review requests table regularly and tell students plainly that feedback arrives in chat.

Skip this if you want requests to find a reviewer by themselves. An unassigned request sits where the student left it.

Creating an admin account and signing in, the step before stage 1.
Chat threads, roles and reply modes, where the feedback lands.
The Teams dashboard, for pending and answered counts.