You rarely create Attachments by hand in modern Salesforce, but it still happens through Data Loader, the API, or Apex when you maintain a legacy object or integration. Here is the shape of creating one, with the strong caveat that new file work should target Salesforce Files (ContentVersion) instead.
- Confirm the parent supports it
Check that the parent object has the Notes & Attachments related list on its page layout. Without it, users will not see the Attachment in the UI even though the row exists. If the object already uses Files, prefer that path instead of adding the legacy related list back.
- Build the record with required fields
Create an Attachment with Name, Body, and ParentId set. Body must be a Blob, so encode or read your file content into a Blob first. ContentType is optional but helps the browser render or download the file correctly.
- Insert and verify on the record
Insert the Attachment through Apex DML, Data Loader, or the REST API. Open the parent record and confirm the file appears under Notes & Attachments and downloads as expected.
- Plan the Files equivalent
For anything beyond a one-off legacy need, create a ContentVersion and a ContentDocumentLink instead. That gives you versioning, multi-record sharing, and visibility in Files Home and mobile that an Attachment can never provide.
The file name shown to users, for example proposal.pdf. Include the extension so the file opens with the right app.
The binary file content as a Blob. Single uploads cap at 25 MB; encode file bytes to a Blob before insert.
The Id of the record the file attaches to. Set once at insert because Attachment cannot be reparented later.
- An Attachment belongs to exactly one parent. If you need the same file on several records, use Files, not multiple Attachment copies.
- Editing the Body overwrites the file with no version history. The previous content is gone, unlike a ContentVersion.
- Attachments do not appear in Files Home, Chatter, or the mobile app, so users accustomed to Files may not find them.