Content Document
A Content Document in Salesforce (ContentDocument in the API) is the standard parent object in the Salesforce Files framework that represents a single file as users see it — the persistent identifier for "this file" across all its uploaded versions.
Definition
A Content Document in Salesforce (ContentDocument in the API) is the standard parent object in the Salesforce Files framework that represents a single file as users see it — the persistent identifier for "this file" across all its uploaded versions. Each Content Document record holds metadata like Title, FileType (PDF, JPG, Office documents, etc.), FileExtension, ContentSize, ContentModifiedDate, OwnerId, the LatestPublishedVersionId pointing to the current Content Version, and SharingPrivacy controls. Content Document is the user-facing record of what most people simply call a "File" in Salesforce — its child Content Version records hold the actual binary content (one row per uploaded version), and its child Content Document Link records connect the file to the records it has been attached to. Content Document is the modern replacement for the legacy Attachment object, supporting multi-record sharing, version history, in-browser previews, library organization, and external sync through Salesforce Files Connect.
In plain English
“A Content Document is the parent record for one file in Salesforce's modern Files framework — like the file itself as you think about it ("the contract PDF"), separate from its individual versions (v1, v2, v3) and from the records it's attached to. The actual binary content lives on related Content Version records.”
Worked example
A solutions consultant uploads a 4MB pricing PDF to Salesforce through the Files tab. Salesforce creates one Content Document record (Title "2026 Pricing", FileType PDF, ContentSize ~4194304, OwnerId her User Id) plus one Content Version record holding the actual binary in its VersionData field. She then attaches the same Content Document to three Opportunities by creating three Content Document Link records — one per Opportunity — each pointing at the single Content Document. A month later she replaces the file by uploading a new version through the Lightning UI; Salesforce inserts a second Content Version under the same Content Document, updates LatestPublishedVersionId, and instantly all three Opportunities see the updated file without any link changes. The Content Document's Id never changes through the file's lifetime — it is the stable identifier external systems and integrations should reference.
Why Content Document matters
Content Document is the parent in the three-layer Files data model: Content Document (the persistent file identity), Content Version (one row per uploaded or replaced version, holding the actual binary in VersionData), and Content Document Link (the junction connecting a Content Document to a record, user, or library). When inserting a file via API, you create a Content Version — Salesforce automatically generates the parent Content Document and the initial Content Document Link. Querying files for a specific record requires joining through Content Document Link with LinkedEntityId set to the record Id, then joining to Content Document for the metadata.
The LatestPublishedVersionId field on Content Document points to the current 'live' Content Version — the one users see when they open the file. Replacing a file uploads a new Content Version and updates LatestPublishedVersionId; previous versions remain accessible through the version history UI but are no longer the default. This versioning model preserves history without breaking links: every Content Document Link still points to the same parent Content Document, and the latest version automatically shows everywhere.
Content Document supports SharingPrivacy ('P' for Private, 'N' for Not Private) to control whether the file can be shared externally through Public Links. Combined with the ShareType field on each Content Document Link ('V' Viewer, 'C' Collaborator, 'I' Inferred from parent record), this two-layer model gives fine-grained control over who can see, edit, share, or delete a file — far more flexibility than the legacy Attachment object's parent-only sharing model.
How organizations use Content Document
Manages a library of current sales collateral as Content Documents, with Content Document Link records sharing files to the appropriate Library and account records. Replacing a Content Document with a new Content Version instantly updates every record where the file is attached, eliminating manual re-distribution.
Receives screenshots and document attachments from customers via Email-to-Case Enhanced Email, which creates Content Document records linked to the originating Email Message. Service agents preview attachments inline in the Case Feed without downloading, and attachments persist through the Case lifecycle as queryable Content Document records.
Maintains every customer-facing document (statements, disclosures, contracts) as version-controlled Content Document records. Each version is preserved indefinitely for regulatory audit, with Content Document Link records providing a queryable audit trail of which documents were sent to which customers and when.
Trust & references
Straight from the source — Salesforce's reference material on Content Document.
- ContentDocument in Object Reference for the Salesforce PlatformSalesforce Developer Documentation
Discussion
Loading discussion…