File Upload

Lets a user attach one or more files to a record.

Where to find it

Architect Panel → Data:

• Datastores — the datastore, then Table Designer to add or edit a field

Architect Panel → Data:

• File Stores — where uploaded files are held
• Large Uploads — sessions for files too big for one request
• Documents — document management, which may suit better

What the field stores

A reference to the uploaded file, not the file itself. The file lives in a file store; the field records which one. Like every media type, it stores text and does not join.

Settle these before going live

1. What may be uploaded. Restrict to the types you expect. An open field accepts anything anybody can produce.
2. How large. Both a per-file limit and an expectation of total volume — files grow faster than records.
3. Where it goes. Which file store, and what its retention and backup arrangements are.
4. Whether it is scanned. See below.

Uploads are the riskiest input you accept

Everything else a user submits is text you control the interpretation of. A file is arbitrary content that something downstream will open.

Virus scanning is available and ships disabled. If your application accepts uploads from outside your organisation — a portal, a public form, a supplier — turning it on is the single most valuable thing on this page. A detected threat can be quarantined and logged rather than silently discarded.

Restrict the types

Accept what you need and nothing else. "Images only" or "PDF and Word" is both safer and kinder — a user who uploads the wrong thing finds out immediately rather than when somebody tries to open it.

Do not rely on the file extension alone as a security control; treat it as a usability aid and let scanning do the security work.

Large files

Very large uploads are handled as sessions rather than as a single request, which is what makes them survivable on a poor connection. If your users routinely upload video or large scans, that is the path to use rather than raising a limit until it works.

Consider document management instead

If files need versions, approval, retention rules, redaction or generation from templates, a file upload field is the wrong tool. The document features exist for that, and retrofitting them onto an attachment field is not straightforward.

Use this field for genuine attachments — a photo of damage, a signed form, a supporting letter — and document management for documents.

Uploaded documents can be indexed

Text can be extracted from uploaded documents in the background so their contents become searchable. That is a scheduled task and it ships disabled, which is worth knowing if you expected to be able to search inside attachments.

Permissions apply to the record, not the file

Think about who can reach a file once uploaded, particularly where files are shared to another store or system. A file attached to a restricted record is only as protected as wherever it now lives.

Worked example

A claims portal accepts photographs and PDFs up to 10MB, with scanning enabled and quarantine on. Larger files go through the upload session path. Supporting evidence stays as attachments; the claim decision letter is a generated document instead, because it needs a template and a retention rule.

Recommendations

• Enable scanning for anything accepting external uploads.
• Restrict the file types you accept.
• Use document management where versions or retention matter.
• Decide the store and its retention before go-live.