A file-upload field can turn a simple form into a privacy and operations problem. A visitor may attach a résumé, contract, photo, log, or spreadsheet when staff only need the request type, deadline, and a short description to choose the next step.
Do not treat every upload as model input by default. Build a review path that starts with the form fields and file metadata, keeps the original attachment in its normal protected storage, and gives a person a clear reason to open it.
Start with the decision, not the file
First, ask what staff decide when an upload arrives. Most first-pass decisions do not require the full file:
- Which team owns the request?
- Did the visitor attach the required file?
- What deadline or service category applies?
- Does the description contain enough detail for a first response?
- Must a qualified person inspect the file before anyone replies?
That list becomes the boundary for the automation. If the first decision can be made from selected text fields plus “attachment present,” file type, and file count, there is no reason to send the file contents to an AI service.
Separate three layers of information
| Layer | Examples | First-pass use |
|---|---|---|
| Form fields | Request type, deadline, location, description | Summarize and route the request |
| File metadata | File present, count, extension, size | Check the upload requirement and assign a reviewer |
| File contents | Document text, images, embedded data | Open only when the task requires it and the handling policy allows it |
For that reason, this separation is a practical version of data minimization. The WordPress privacy guidance recommends thinking about the personal data a site collects and why the site needs it. Sentient Forms applies the same discipline to action inputs: send only the fields the action needs.
Make the upload field explain itself
Next, visitors should know what to attach, which formats the form accepts, and whether the file is optional. The W3C form instructions tutorial recommends putting instructions where people can find them before they make an error.
Use plain language beside the upload field. For example: “Attach the floor plan if you have it. PDF or image, 10 MB maximum. Do not include payment details.” Configure allowed extensions and limits in the Form Source itself; Gravity Forms, for example, documents these controls in its File Upload field guide.
Instructions will not stop every unsuitable upload, but they reduce preventable cleanup and give staff a written rule for rejecting or escalating a file.
Build a metadata-first action
Then, map the minimum useful fields into the action. A practical review packet might contain:
- the visitor’s stated goal and requested date;
- the service or request category;
- whether the visitor attached a file and how many files they supplied;
- the file extension or another non-content cue staff need;
- a short summary, missing-information flag, and recommended owner.
Therefore, an Entry Summary can condense the selected form fields, while Missing Information Review can flag gaps in the request. Neither requires you to promise that staff or the action read the attachment. Say “attachment present” when that is all the workflow knows.
Keep a person in the file decision
However, the action result should tell staff why the file needs review, not decide what the file proves. A contract, medical image, identity document, résumé, or legal record can carry consequences that exceed a first-pass automation.
Use automation to prepare the review. Do not let it invent a review that never happened.
Finally, record the result in the appropriate native entry surface or Sentient Forms Submission Ledger, depending on the Form Source. Current support depth differs: Gravity Forms has the deepest native integration; Contact Form 7, WPForms, and Elementor Pro Forms support after-submission workflows through the ledger. Do not assume the same native notes, statuses, or controls exist everywhere.
Test the exceptions before launch
Before launch, run a small set of real-path tests:
- a valid request with no optional attachment;
- a valid request with one allowed file;
- a missing required upload;
- an unsupported extension or oversized file;
- a vague description that should go to human review;
- a submission containing sensitive details that must stay out of the action input.
Check what the site stored, what the action received, what staff can see, and how long each record remains. Add the decision to an AI form review audit trail, and align it with the site’s published privacy policy.
A small boundary saves work later
A metadata-first path is easier to explain, test, and hand off. Staff get a useful review packet. Visitors get clearer upload instructions. The attachment stays out of the model path until a real task and an approved handling rule require it.
Not by default. Start with the selected form fields and the minimum file metadata needed for routing or completeness checks. Send file contents only when the task requires them, the handling policy allows it, and a person can review the result.
The workflow may need to know whether the visitor attached a file, how many files they supplied, and the permitted extension or size. Pair that metadata with the request type, deadline, description, and owner rather than assuming anyone reviewed the file contents.
Test the real form path with allowed, missing, unsupported, oversized, vague, and sensitive examples. Verify what the action received, where the result appears, how a person reaches the attachment, and how long the site retains each record.
