Salesforce File & Storage Glossary

Quick reference for the terms used across our Salesforce migration and archiving tools. Each entry is two or three sentences — enough to recognize the object or concept and how it fits into a file or data migration.

ContentVersion #

A single version of a file. Each upload to Salesforce creates a new ContentVersion row, using the 068 ID prefix. Every ContentVersion belongs to a parent ContentDocument, and the actual binary lives in its VersionData field.

ContentDocument #

The wrapper record for one or more ContentVersions of a file. ContentDocument uses the 069 ID prefix (its child ContentVersion uses 068) and holds file-level metadata such as title, file type, and the latest published version pointer. It does not store the binary itself — that lives on its ContentVersion children.

ContentDocumentLink #

The join object that links a ContentDocument to a parent record such as Account, Case, or Opportunity. One file can be linked to many records via multiple ContentDocumentLink rows, which is how Salesforce supports sharing the same file with multiple objects without duplicating the binary.

Attachment #

Legacy Salesforce file storage object using the 00P ID prefix, predating Lightning and the modern Files model. Salesforce no longer recommends Attachment for new files — new uploads default to ContentDocument — but most older orgs still hold large volumes of legacy Attachment records that need to be counted, migrated, or archived.

Note #

Two flavors. The classic Note object uses the 002 ID prefix and stores plain text on a parent record. The modern ContentNote rides on the Content* file model (so it surfaces as a ContentDocument with ContentNote as its file type). Both appear under the Notes UI, but they live in different objects.

ContentDocumentArchive #

The Salesforce-managed archival object created when a ContentDocument is archived. Archiving frees user file storage from the active org while keeping the file metadata discoverable through the archive surface. Useful when retention rules require keeping a record of the file but day-to-day users don't need to see it.

Bulk API 2.0 #

Salesforce's high-throughput REST API for processing large record sets asynchronously. It has higher per-call limits than the regular REST API and is the right choice for migrations above a few thousand records. Job state is tracked server-side, so clients poll for completion rather than streaming everything in one request.

External ID #

A custom field flagged as External ID that lets you upsert records by a non-Salesforce identifier — typically a primary key from the source system. External IDs are essential for cross-org migrations: they're what lets you map a child record's foreign key to the right parent in the target org without round-tripping through the Salesforce Id.

ContentVersionFile (binary) #

The actual blob content of a Salesforce file — the bytes referenced by a ContentVersion's VersionData field. It's streamed via the REST endpoint /sobjects/ContentVersion/{id}/VersionData rather than returned inline by a SOQL query, which is why file migrations have to make a separate call per file to pull the contents.

Sharing visibility #

On ContentDocumentLink, the ShareType (V = Viewer, C = Collaborator, I = Inferred) and Visibility (AllUsers or InternalUsers) fields that govern who can see a file. Two links on the same file can have different settings, which is how one file can be read-only to one record's audience and editable to another's.

API call limit #

Daily cap on REST + Bulk API calls per Salesforce org. Typical baseline is 15,000 calls per licensed user per day, with edition-based floors and ceilings. Migrations have to budget against this — a naive script pulling a million files one at a time will exhaust the limit long before it finishes.

ContentDocumentLink LinkedEntityId #

The LinkedEntityId on a ContentDocumentLink is the record (Account, Case, Opportunity, etc.) the file is shared with. It's the single most common cross-org migration failure point: the target org doesn't yet contain the parent record the link points to, so the link insert fails. Migrating files between orgs almost always requires migrating the parent records first, then mapping their old Ids to new Ids before creating the links.