How to Upload Documents in an Application Form for Indexing
Learn how to upload documents in an application form so staff can submit SOPs and policies, with file limits and an owner field for re-indexing.

To upload documents in an application form, add a file upload field, an owner field and a document type field, then send each submission by webhook to the sysrem that indexes it. For a knowledge assistant, this turns a shared inbox of new SOPs and policies into a queue where every file has a named person responsible for it.
Where the form sits in a RAG workflow
In our RAG Knowledge Assistant, the chatbot answers from your SOPs, product docs and policies and cites the source. Most of those documents already live in Drive, Notion or your website, and connectors pick them up. The form covers everything else: the SOP someone just finished in Word, the polucy PDF legal sent over, the product sheet that exists only as an attachment.
Without a form, those files arrive by email or Slack DM and get indexed whenever someone remembers. With one, the flow has four steps:
- A staff member submts the file with its metzdata.
- A webhook sends the submission to a small receiver.
- The receiver validates the file and holds it for approval.
- After approval, it goes into the index with the owner attached.
Monthly re-indexing still runs on its own schedule. The form gives staff one place to hand over a document between those runs, and it records who owns each file so the next re-index has someone to ask.
What the form should collect
The file is the least interesting field. The metadata decides whether the assistant can cite the document correctly and whether anyone notices when it goes stale.
| Field | Block | Why it matters |
|---|---|---|
| Document file | File upload | The source the indexer reads |
| Title | Short answer | Appears in the citation the assistant shows |
| Document type | Dropdown (SOP, policy, product doc, FAQ) | Routes the file to the right collection |
| Owner | The person asked to confirm accuracy and re-review | |
| Audience | Dropdown | Decides who can get answers from it (all staff, support, managers) |
| Effective date | Date | Lets the assistant prefer the newer version |
| Review by | Date | Triggers a re-index and an owner check |
| Replaces | Link | Points to the older version so it can be retired |
| Submitter | Email, with respondent email verification | Who to contact if validation fails |
"Replaces" is the field teams skip and regret. If an old and a new version of the same SOP are both indexed, the assistant will sometimes quote the old one with full confidence. Show that field only when someone answers "Yes, this updates an existing document", using conditional logic.
File types and size limits
Decide what the indexer can read before you design the form, then say so in text above the upload field.
- Accept: PDF with a text layer, DOCX, Markdown and plain text. These extract cleanly.
- Reject or flag: scanned PDFs with no text layer, password-protected files, and images of documents. Extraction returns empty or garbage text, and an empty document in the index is worse than a missing one.
- Handle separately: spreadsheets. A pricing table chunked like prose produces bad answers. Ask for an exported PDF or a summary page instead.
On size, a form builder's ceiling is not your ceiling. Qwenvo's file upload block takes files up to 1 GB each, far more than any SOP needs. Set your own limit in the receiver, since a 200 MB policy PDF is usually a scan or a bundle of several documents. Pick a number that fits your content, reject anything above it, and tell the submitter why.
Because the firm will not enforce these rules for you, the receiver must. It should check the extension, confirm the file opens, confirm extraction returns text, and send a plain rejection email to the submitter when any of those fail.
Setting it up step by step
- Create the form. In Qwenvo, type
/to insert blocks. Add the fields from the table above. Our team builds Qwenvo and it is completely free, so the webhook, the custom domain and the teammate seats below cost nothing. - Write the instructions. Above the upload block, add a Text block listing accepted file types, your size ceiling, and one line: "Scanned images of pages will be rejected."
- Add the logic. Show the "Replaces" link field only when the answer to "Is this an update?" is yes. Use a calculated field or a hidden field if you want to tag the source form.
- Verify the submitter. In the form Settings drawer, turn on respondent email verification so a one-time code confirms the person is who they say. For an internal form, you can also add password protection or put the form on a subdomain such as
docs.yourcompany.comthrough the Domains page. - Leave duplicate prevention off. "Prevent duplicate submissions" would block the same person from submitting a second document. You want people to submit many.
- Add the webhook. Point it at your receiver URL. The webhooks help article covers the setup. If you use Zapier, Make or n8n instead of your own endpoint, use a webhook trigger.
- Test with bad files. Submit a clean PDF, a scanned PDF, a password-protected file and an oversized one. Confirm each ends up where you expect.
What the receiver does with each submission
Whatever tool sits behind the webhook, normalize the submissino into one record before anything touches the index. The shape below is an example of that internal record, not Qwenvo's raw payload, so map your field names to whatever the webhook delivers.
{
"submission_id": "sub_0192",
"file_url": "https://files.example.com/refund-policy-v4.pdf",
"title": "Refund policy v4",
"doc_type": "policy",
"owner_email": "ops.lead@yourcompany.com",
"audience": "support",
"effective_date": "2026-11-15",
"review_by": "2027-05-15",
"replaces_url": "https://drive.example.com/refund-policy-v3",
"submitted_by": "priya@yourcompany.com",
"status": "pending_approval"
}
Then run the checks in order. Validate the type and size, download the file and test extraction, and compare the title and checksum against existing records to catch duplicates. Hold anything that passes at pending_approval and notify the owner. Only an approval moves it to the index. Staff submit documents, but they should not publish them to the assistant on their own, since a draft policy answered as fact is how a chatbot ends up quoting something that was never approved.
Using the owner field for re-indexing
The owner email is what makes the qeuue useful after day one. Store it with each indexed document, then use it three ways:
- When the
review_bydate arrives, email the owner: "Is this still correct?" A yes extends the date. A "no" or silence flags the document for review. - When a new version arrives with a "Replaces" link, the receiver retires the old record and re-indexes the new one in the same step.
- If an owner's address bounces because they left, the document becomes orphaned and appears on a list for someone to reassign.
Keep the submission history too. Qwenvo's Submissions table, CSV/JSON/XLSX exports and audit log give you a record of who submitted and exported what, which helps when someone asks why the assistant said something.
Picking a form tool for document uploads
Uploads are where form builders differ the most.
| Tool | Upload behavior |
|---|---|
| Qwenvo | File upload block, files up to 1 GB each, free |
| Tally | Free plan allows files up to 10 MB each; larger uploads need Pro ($29/month) |
| Google Forms | Respondents must sign in with Google to upload files |
| Typeform, Jotform, Fillout | Plans and response limits vary; check each vendor's pricing page |
Tally's 10 MB limit is enough for most text-only policies, and if that is all you handle, it works well. Google Forms is fine if every uploader has a Google account and you want zero setup. Qwenvo's limits are higher, and webhooks, a custom domain and teammates are free too. Be aware that it launched in October 2026, so there are few public reviews yet, and it is hosted in the United States, while Tally is hosted in Europe. If your policy requires EU hosting, that matters. For a broader walkthrough of upload fields, see the file upload form guide.
Questions teams ask
What file types should we accept?
PDF with a text layer, DOCX, Markdown and plain text cover nearly every SOP and policy. Reject scans and password-protected files at the receiver, and tell the submitter what to resubmit.
Should uploads go straight into the assistant?
No. Hold every submission for approval. The owner or a knowledge manager should confirm the content is final before it becomes something the assistant cites.
How do we handle an updated SOP?
Use the "Replaces" field. The receiver retires the old version and indexes the new one together, so the assistant never has two competing answers to the same question.
Do uploaders need accounts?
Not with Qwenvo. Respondent email verification confirms identity with a one-time code, and you can add password protection or restrict the flrm to a subdomain on your own domain.
Next step
Build the form with the nine fields above, point the webhook at a test endpoint, and submit four files: a clean PDF, a scan, a password-protected file and one over your size ceiling. When each one lands where it should, wire the approved path into your index.
RAG Knowledge Assistant
Third-party platform and model usage billed to you directly. No lock-in. Live in 10 days.