How does Salesforce Files actually work under the hood?

Salesforce Files uses three core objects and a CDN-backed file store.

• ContentDocument — the conceptual file. Has a Title, Owner, file extension, latest-version pointer.
• ContentVersion — a specific binary version of a file. New versions are created on every edit; the old version remains queryable.
• ContentDocumentLink — a join row connecting one ContentDocument to one related record (Account, Opportunity, Case, etc.). One ContentDocument can have many ContentDocumentLinks if the file is shared with multiple records.

Sharing model:

• A user can see a file if they (a) own it, (b) have a ContentDocumentLink to a record they have access to, or (c) are explicitly granted access via the Files sharing dialog (ContentDocumentLink with LinkedEntityId of a User or Group).
• Public Links — generated for guest sharing, optionally password-protected, with an expiry date.

Storage:

• File storage is separate from data storage in your org's allocation — it has its own quota.
• Per-file size limits depend on upload method: 2 GB per file for Lightning UI uploads, 38 MB for SOAP API, higher for Chatter REST API.
• Files are stored in the org's region (US, EU, AP) according to where the org is provisioned.

What admins typically do:

1. Migrate from Attachments. New orgs default to Files; old orgs may have years of Attachment data. Migration packages exist to convert.
2. Manage public links — review and expire stale ones; this is a security audit item.
3. Configure file upload security — Setup -> File Upload and Download Security restricts which file extensions can be uploaded (block .exe, .bat, etc.).
4. Storage cleanup — old versions accumulate; admins schedule cleanup via Apex or third-party tools.

A common admin tip: encourage users to share Files via the Files component on the page, not via legacy Attachments. The Files component has versioning, sharing controls, and easier discovery.