Understanding how uploaded files become forms
Last updated: October 21, 2026
When you upload a document or paste text, Onboarded converts it into a draft form. The draft is where your review starts, not a finished form ready for candidates.
What it is
Onboarded can build a form out of something you already have: a PDF of a tax form, a policy packet, a state notice, or text like a survey export or a description of the form you want. You upload the source, and Onboarded reads it and produces a draft form: pages, fields with types, read-only content, and, for a document, a mapping back onto it so a completed form can be written onto the original.
If you remember nothing else: conversion produces a draft, and every draft gets a human review before candidates see it.
Why it matters
Most forms in your account start life as a document somebody handed you. Conversion removes the transcription work (laying out pages, typing labels, choosing field types), which is the slow part of building a form. What it doesn't remove is the judgment: whether a field is required, whether a step stays hidden for some candidates, whether the acknowledgment language survived intact.
Knowing the shape of a conversion tells you where to spend your review time, and explains the build columns on your forms list, the most common question after a first upload.
This matters most when:
You're standing up a new account with a stack of documents to bring in.
You upload a long document and get back a short form, which is often correct, for the reason in the example below.
A form comes back with fewer fields than the source, and you need to tell a miss from a deliberate choice.
How it works
What a conversion produces
Onboarded reads the source and writes a new form with a draft version. That draft holds the pages, the fields (each typed as a date, a currency amount, a signature, a tax ID, and so on), and any read-only content the form needs to display. What else it holds depends on the source:
A PDF stays attached to the form, and its fields are mapped back onto it. The
PDFview in Form Studio shows you the original next to what was built from it.An HTML file is turned into a fillable PDF first, then converted the same way as a PDF.
Text, whether pasted or uploaded as a
.txt,.json,.md, or.csvfile, describes the form rather than being one. The form is built from it, but there's no PDF behind it to map onto.
Conversion never touches a deployed version. A form already in use keeps serving candidates while a new draft sits alongside it.
Reading the build columns
Two columns in Forms → My Forms tell you where a conversion stands. AI build says how the build went. Waiting for says whose turn it is.
Column | What you see | What it means |
|---|---|---|
|
| The conversion is running. Nothing for you to do yet. |
|
| The conversion finished cleanly. |
|
| The conversion finished, but Onboarded flagged parts of the draft to check. |
|
| Onboarded couldn't build a form from the source. Usually the file's contents aren't a format Onboarded reads, whatever its extension says, or the document is in a language your organization doesn't support. |
| Your organization's name | The draft is yours to review. |
|
| The form is marked as Onboarded's turn. That happens when you checked |
When a build finishes, the form is handed to someone automatically. A clean build goes to your organization. A build with problems, or one that failed, is marked as waiting on Onboarded. If Request Onboarded support was checked at upload, the form goes to Onboarded either way, with your instructions as the first note, and the Onboarded team picks it up from there. To pass a form back and forth after that, see 📄 How do I review and hand over forms that were built for me?
Without Request Onboarded support, a Built with problems or Failed status doesn't open a support request on its own. For Built with problems, open the draft in Form Studio and fix what was flagged, or use Rebuild with AI. For Failed, check the source file and its language, then upload it again. If you need help with either, contact Onboarded support, or your partner's support team if you work with Onboarded through a partner.
The AI build column only shows a result while a form is in review. Once the form is deployed, the column goes blank, and the form's Build card keeps the record.
Document type shapes the result
Every file you upload carries a document type, which tells Onboarded what kind of document it's reading. Auto-detect reads the document and picks a type, and you can override it per file.
The type matters because the right output for one kind of document is the wrong output for another. A tax form wants precise numbered fields. A handbook wants a short acknowledgment.
Document type | What it's for |
|---|---|
| Content-heavy handbooks, posters, and notice packets that are mostly verbatim text with few real inputs. |
| Disclosures, consents, and notices whose body is read-only text and whose only input is an acknowledgment. |
| Government tax and withholding forms (the W-4 family) with precise, numbered fields. |
| Forms that establish who someone is from the documents they present (the I-9 family): a set of acceptable documents, a choice between them, and an examination step. |
| Training tests and survey exports: a document that teaches and then asks questions, or a list of questions with the correct answers marked, graded when the candidate submits. |
| Standard data-collection forms with no document-type specialization, like self-identification forms, screening questionnaires, and notices. |
Auto-detect never picks Policy / disclosure. It reads background-check documents and notices as Generic, so choose Policy / disclosure yourself when you want that treatment. If a form came back built as the wrong type, use Rebuild with AI on its Build card and pick a different Document type. The rebuild replaces the latest draft, so edits to that draft are lost.
Language
Onboarded detects the language of the source and builds the form in that language. Any additional languages you pick under Output language are translated from it, so the detected language is the one the translations derive from. If the detected language isn't one your organization supports, the build fails. Add the language to your organization's supported languages and upload again.
A converted form is a draft, not a live one. Candidates don't see it until you deploy it.
Onboarded also records what it wasn't confident about, as findings with a severity, and shows them in Form Studio's AI panel as you work. A conversion with no findings isn't a promise that every field is right for your process. It means nothing tripped the checks.
Built means the conversion finished, not that it went perfectly. A form built from a scanned or image-background PDF can arrive with few or no fields, because the labels were pixels rather than text. Open every draft before you count on it.
Example
Take an account bringing in a 40-page state labor-law poster packet. The source is almost entirely statute text, with one signature line at the end.
Converted as Handbook / posters, the result is a single page: a short summary naming each posted notice, a link to the full packet, the acknowledgment sentence, and a signature field. Not 40 pages of inputs.
That's the intended outcome. Turning the packet into form fields would hand a candidate hundreds of boxes for a document they were meant to read, not fill in. Your review here is about confirming the acknowledgment language is verbatim and the link resolves, not hunting for missing fields.
A tax document goes the other way. Converted as Tax / withholding, a W-4 comes back with the official step and line numbers preserved in the labels, dollar amounts typed as currency, computed lines carried as formulas rather than boxes the candidate adds up, and the exemption path gated so someone claiming exemption doesn't see the middle steps. There your review is about the branching.
Same conversion, two very different shapes, which is why the document type is worth setting deliberately when you know what you're uploading.