Say you have fifty PDFs to turn into assistants.
Docutrain will not swallow all fifty in one gulp. Six documents can be queued at once, and they train strictly one at a time. But the queue is built so each batch of six costs you about a minute of attention and then runs unattended, which is the number that actually matters when you are working through a pile.
Queuing applies to files. The text, audio and web tabs handle one item at a time.
Set once, apply to all
The thing that makes a batch fast is the Defaults for all strip at the top: an access level, a category, and the auto-cover switch. Every file you add inherits them, and changing a default updates every file you have not deliberately set otherwise.
Then, when one file in the batch needs to be different, click its card and change it there. That field is marked "· overrides default", and later changes to the batch defaults leave it alone.
The queue row shows your files as cards with chips summarizing each one's settings, and a chip is highlighted when it overrides the batch default. So the odd one out is visible at a glance rather than something you discover after publishing. For anyone who has ever set fourteen documents to the wrong access level in one go, that highlight is the feature.
Two details catch people out. The batch Access menu does not offer Passcode, because there is nowhere in that strip to type one; choose it on an individual file's panel, where the passcode field appears alongside. And token-link access is not offered before upload at all, since tokens are issued against a saved document. Set it afterwards (access levels explained).
What stops you before you waste time
Two checks run before anything is sent.
A file set to passcode access with no passcode blocks submission and names the file. Not a red asterisk somewhere off-screen, the actual filename in the message.
And your plan's remaining allowance is taken into account, including documents already in flight, so the queue never offers more slots than your plan can hold. With one slot left, you get one slot. Worth knowing before you sit down with fifty files rather than after twelve of them fail. See plans and limits.
Everything you set is stored with each upload and applied the moment the document is created, so there is no tidying-up pass afterwards.
While it runs
Each document appears in the Processing panel, the one being trained first, the rest marked Queued. When one finishes, fails or is cancelled, the next starts by itself.
The part worth trusting: if the server restarts or a hand-off is lost, a background sweep picks the queue back up. Documents left waiting get started rather than sitting there stranded until somebody notices at four o'clock.
You do not get a completion window per file, which would be intolerable across a batch. Once the whole queue drains, a single Training complete window lists what finished and confirms your settings were applied.
Email arrives separately, one message per document, either "Document ready" with the page count and share link, or "Processing failed" with the error and a retry button. If a failed job is retried automatically, you are emailed only for the first and final attempts, so a flaky file does not produce six identical emails.
Cancelling and recovering
Cancel spells out the consequence before you agree to it: processing stops at the next checkpoint, the document is marked failed, and you can retry or delete it. Queued documents cancel the same way, and cancelling one frees its slot so the next starts immediately. Useful the moment you realize the third file was last year's version.
Some recovery is automatic. If the server is at capacity when your upload tries to start, you get "Server busy. Retrying in 30 seconds... (attempt 1/4)", with the delay increasing to 60, 120 and 240 seconds. Keep the page open and it begins as soon as capacity frees up.
The rest is manual, and specific. A document that ends in error turns its card into a panel naming the error, the file size, and the upload and failure times. Retry runs the pipeline again, and is deliberately not offered when the error was that the document is too large, because retrying an oversized file achieves nothing. Split it instead.
Delete removes the failed upload so it stops counting against your document limit, which matters when you are near the ceiling and the failure is what is blocking the next attempt. A card reading Stuck offers Force Retry. Common causes are in troubleshooting common issues.
Fifty files that should have been one
Sometimes a pile of PDFs wants to be a single assistant rather than fifty. The Combine bulk action in the library merges several trained documents into one new one.
The window is explicit. The originals are untouched, and the result is a snapshot that will not update when the sources are retrained, and cannot be retrained itself. Sources with no content yet are skipped and named rather than silently dropped.
The copy runs from your browser, with a progress bar naming each source as it goes and a reminder not to close the tab. Once the text and images are copied, an introduction and keywords are generated from the combined content, and at that point you can close the window and let generation finish in the background.
Each copied passage is prefixed with its source document's title, so citations in the combined assistant still tell a reader where a passage came from.
If a combine never finishes because the tab was closed mid-copy, the half-built document sits in the library with a red, unclickable Incomplete chip. Delete it and combine again. It will not pretend to be a working assistant.
The rhythm
For a genuinely large pile, the workflow that works is: sort the files into groups that share an access level and category, then queue a group at a time, setting the defaults once for each.
Six files, one minute, walk away. The queue does the waiting.