AI app guides
Design file uploads so an interruption does not lose the whole request
Keep the business record, attachment status and replacement path understandable when a file cannot be uploaded.
Zocri · 2 min read · Sources checked
Keep the request separate from the file
OWASP recommends explicit file-size limits and validation of uploaded file types rather than trusting the declared content type alone. Pair those controls with a clear business workflow. A customer may spend time describing a repair before attaching a photo. If the photo fails, decide whether the description can remain as a draft or submitted request awaiting an attachment, rather than forcing the person to begin again.
Explain the accepted formats and size limit before the user chooses a file. If a photo is optional, say so. If it is required for review, show that the request remains incomplete until the attachment succeeds. The interface should reflect the business rule instead of treating every upload failure identically.
Show progress and a truthful result
Use distinct states for selected, uploading, received and failed. A filename appearing in the form only shows that a file was selected; it does not prove that the app has stored it. Avoid a general success message until the relevant step is actually complete.
When an upload is refused, identify the reason the user can act on, such as unsupported format or excessive size. Keep technical detail available to the appropriate operator without exposing it as an unexplained error to the customer. Preserve the rest of the form where the chosen design allows.
Provide a replacement path
Let a user remove a mistaken selection before submission and replace an attachment afterward if policy permits. Show which version is current and whether a reviewer has already acted on it. An old link should follow the app's access rules even after a new file replaces it.
For an interrupted connection, offer retry or return-later behavior that matches the actual implementation. Do not call a feature resumable merely because the button says resume. Ask the builder to demonstrate what happens to partially transferred data and whether retrying creates duplicate attachments.
Test from both sides
Use a small valid file, a large file, an unsupported format and an interrupted transfer in an authorized test environment. Refresh after a successful upload and verify that the owner can open the correct attachment. Then check that an unrelated user cannot retrieve it through a copied link.
Review the incomplete queue from the owner's perspective. They should know whether the customer still owes a file or whether a technical failure needs attention. A good upload journey preserves the person's effort, communicates the real state and provides a specific next action when the attachment is not ready.