File and image columns

What it does

File and Image columns store binary data outside the relational store, which is why they perform better and consume different capacity from ordinary columns. File takes any binary payload; Image is specifically for pictures and gets thumbnail treatment.

Key facts

File columns default to a 32 MB maximum size, and the largest you can set in the designer is 131,072 KB (131 MB). The maximum can't be changed once saved.
You can add more than one file column to a table. Image is different — each table gets one primary image, and image columns are always named tableImage regardless of the name you type.
Image maximum size defaults to 10,240 KB, with a range of 1 KB to 30,720 KB. Uploads must be under 30 MB and in jpg, jpeg, gif, bmp or png.
Every uploaded image is converted to jpg, and resized to a thumbnail with a maximum of 144 x 144 pixels, cropped square. Animated gifs keep only the first frame.
Displaying a primary image on a model-driven form takes two settings: the table's Primary Image property pointing at the column, and Show image in the form on the form itself.
Neither type works with business process flows, business rules, charts, rollup columns or calculated columns. Required-field validation doesn't apply to file columns.
Images can't be enabled for search or sorting. Files can't be sorted.
Both can be secured with column-level security, but neither can be masked.
In model-driven apps, uploading or deleting a file happens immediately rather than on form save. Discarding changes doesn't bring a deleted file back.
For capacity, any custom or standard table with a file or image (full size) column counts against file storage, alongside Attachment, AnnotationBase and web resources.

When to use / skip

Use a file column when the document belongs to the row as data — a signed form, a generated PDF, a proof of delivery — and you want it retrievable through the same API as everything else. Use notes and attachments, or SharePoint integration, when users are managing documents as documents, with versions and co-authoring and folders. The honest position is that Dataverse is a poor document management system and a perfectly good binary column store, and clients conflate the two constantly. On images, remember the 144 pixel thumbnail: it's for avatars and record icons, not for anything anyone needs to actually look at.

Configuration decisions

File maximum size per column, set once and permanently, so pick a ceiling that reflects real payloads with headroom.
Whether documents belong in Dataverse at all or in SharePoint with document management enabled.
Whether the image column is the primary image, given there's only one per table.
Whether the column needs column security, accepting that masking isn't available for either type.
How files are retrieved by integrations, since binary columns come back through a different pattern from ordinary column data.

Gotchas

The image thumbnail is the one that generates complaints. Users upload a photo of a damaged part, it comes back as a cropped 144 pixel square, and they conclude the system is broken. Use a file column for anything that needs to be viewed properly.
File maximum size being immutable means an under-sized column has to be replaced, and replacing it means migrating the binaries.
File deletes on a form are immediate. There is no undo, and "I clicked cancel" doesn't help.
File storage is a separate capacity bucket from database. Excess file capacity can't cover a database or log deficit, and excess database capacity can't cover a file deficit either. Watching one number tells you nothing about the other.
No required-field validation on file columns, so "the user must attach the document" needs enforcing somewhere else entirely.

Consultant notes

Have the SharePoint versus Dataverse conversation before anyone builds an upload control. It's an architecture decision with a storage cost attached, and revisiting it after go-live means moving files.
Model the capacity. Rows per year multiplied by average file size, presented as a number, is what stops a client casually agreeing to store scanned post in Dataverse.
Warn the client that the primary image is a small square thumbnail. Show them one during design so nobody's surprised at UAT.
If files are going in Dataverse, agree the retention and purge story early. File capacity only goes one direction unless somebody deliberately cleans up.

Revisit if image handling ever keeps full-resolution originals, or if the file size ceiling moves.