Attachment

An Attachment in Salesforce is the legacy standard object (Attachment in the API) that stores a single file uploaded to a parent record through the classic Notes & Attachments related list. Each Attachment record contains the file's Name, binary Body (up to 25 MB, base64-encoded), ContentType (MIME type), BodyLength, a polymorphic ParentId pointing to almost any standard or custom record, an OwnerId, an IsPrivate flag, and an optional Description. Attachments are tightly coupled to a single parent — there is no built-in way to share one file across multiple records, and the file disappears if the parent record is deleted. Salesforce Files (ContentDocument and ContentVersion) replaced Attachments as the modern file-storage model, offering multi-record sharing, version history, preview rendering, external sync, and rich permission controls. Salesforce continues to support the Attachment object indefinitely for backward compatibility, but new file uploads through Lightning Experience and most current APIs default to Files instead.

Attachment storage counts against the org's File Storage allocation, which is allocated separately from Data Storage. Each Salesforce edition includes a base allotment plus a per-user multiplier — running out of file storage is a common surprise in older orgs with high Attachment volume. Attachment Bodies are stored base64-encoded, which means a 1 MB raw file consumes roughly 1.33 MB of storage when measured against the limit. Bulk export of Attachments through the Bulk API is a common data-archival pattern for orgs cleaning up legacy storage.

The Attachment object's tight one-to-one parent relationship is its single biggest limitation compared to Files. You cannot link the same Attachment to two records — the same file uploaded to ten Opportunities means ten Attachment records, each consuming its own storage. ContentDocument solves this through ContentDocumentLink junction records, allowing one underlying file to be shared with many records and many users, each with its own access level (Viewer, Collaborator, Owner).

Permissions follow the parent record's sharing model, with the IsPrivate flag adding a single-owner restriction (similar to classic Notes). There is no field-level security on Attachment, no folder structure, no version history beyond replacing the file (which deletes the previous version's data), and no preview rendering — clicking an Attachment downloads it. These gaps are why Salesforce Files exists, and why almost all modern documentation assumes Files unless explicitly discussing legacy Classic behavior.