What metadata is stored in Salesforce when files live in S3?

When files live in Amazon S3, Salesforce stores a metadata record inside its own database that acts as a pointer to the external file. This record captures key identifiers such as the file name, content type, file size, the linked S3 object key or URL, and the associated Salesforce record ID. The actual file bytes live in S3, but all the descriptive and relational data stays in Salesforce. The sections below unpack exactly what that means for version tracking, search, compliance, and day-to-day retrieval.

Where does Salesforce actually store metadata when files are in S3?

When a file is stored in S3, Salesforce stores its metadata inside the Salesforce database itself, not in S3. The S3 bucket holds the binary file content, while Salesforce maintains a structured record that describes the file and connects it to the correct Salesforce record or object. This separation is fundamental to how Salesforce external file storage works.

In practice, this means the S3 bucket functions as a raw storage layer, and Salesforce functions as the intelligence layer. Every time a user interacts with a file from within a Salesforce record, the platform reads its own internal metadata to know where to look in S3, what to display, and who has access. The two systems work in tandem, but the metadata home is always Salesforce.

What metadata fields does Salesforce keep for S3-linked files?

For files linked to S3, Salesforce typically stores a core set of metadata fields that allow it to identify, describe, and retrieve the file. These fields are held in Salesforce objects such as ContentDocument or custom external file records, depending on how the integration is configured.

Common metadata fields include:

• File name and extension — the human-readable label for the file
• Content type or MIME type — identifies whether the file is a PDF, DOCX, image, and so on
• File size — recorded at the time of upload
• S3 object key or storage path — the unique reference Salesforce uses to locate the file in the S3 bucket
• Owner ID — the Salesforce user who uploaded or owns the file
• Created date and last modified date — timestamps tied to the Salesforce record, not necessarily the S3 object
• Parent record ID — the Salesforce record the file is attached to, such as an Opportunity, Account, or custom object

What Salesforce does not automatically store is custom S3 object tags, S3 bucket-level metadata, or any enriched attributes you may have applied directly in AWS. Those fields exist only in S3 unless your integration explicitly maps them back into Salesforce fields.

Does Salesforce track file versions when files are stored in S3?

Version tracking for S3-stored files depends entirely on how the integration is built. Native Salesforce Files (ContentDocument and ContentVersion) support versioning within Salesforce, creating a new ContentVersion record each time a file is updated. However, when the file content lives in S3, the version record in Salesforce captures the metadata of that version, while the actual versioned file bytes must be managed either by S3 versioning or by the integration layer itself.

If S3 bucket versioning is enabled on the AWS side, S3 keeps a history of every object version using its own version ID system. The challenge is that Salesforce does not automatically know about those S3 version IDs unless the integration is explicitly designed to write them back into Salesforce metadata fields. Without that mapping, you can end up with version history in two separate systems that do not talk to each other, which creates real operational risk for teams managing contracts, project files, or compliance-sensitive documents.

What’s the difference between native Salesforce Files metadata and S3-linked file metadata?

The key difference is completeness and control. Native Salesforce Files store both the file content and all metadata entirely within Salesforce, giving you a single, consistent record that includes version history, sharing rules, preview capabilities, and full search indexing. S3-linked file metadata, by contrast, is a partial record — Salesforce holds the descriptive fields, but the file content is external, which introduces gaps depending on how tightly the integration is configured.

With native Salesforce Files, every metadata field is automatically populated and kept in sync. With S3-linked files, the metadata in Salesforce is only as complete as what the integration writes to it. If the integration does not capture a field — say, a custom category tag or a document classification label — that information either lives only in S3 or is lost entirely. For document metadata management at scale, this gap matters significantly.

Native files also benefit from Salesforce’s built-in content search, which indexes file text for full-text search. S3-linked files typically do not get that same indexing unless the integration explicitly pushes extracted text back into a Salesforce field.

How does Salesforce retrieve file metadata from S3 when a record is opened?

When a user opens a Salesforce record that has S3-linked files, Salesforce reads the metadata record stored in its own database first. That metadata record contains the S3 object key or URL, which Salesforce then uses to generate a secure, temporary access link to the file in S3. The file content itself is streamed from S3 on demand, but the metadata display happens instantly from Salesforce’s own data layer.

This retrieval pattern means that file listing, file names, dates, and owner information all load from Salesforce without touching S3. Only when a user actually opens or downloads the file does the request reach the S3 bucket. This design keeps the user experience responsive, but it also means that if the Salesforce metadata record is inaccurate or incomplete, users may see misleading file information even before they attempt to open the file.

Can Salesforce search and filter files stored in S3 using metadata?

Yes, Salesforce can search and filter S3-stored files, but only using the metadata fields that have been written into Salesforce records. Any attribute stored exclusively in S3 — such as custom S3 object tags or AWS metadata headers — is invisible to Salesforce search. This is one of the most important practical limitations of Salesforce S3 integration for teams that rely on fast document retrieval.

For example, if your integration stores the file name, content type, and parent record ID in Salesforce, users can filter files by those fields using SOQL queries, list views, or reports. But if a document classification tag like “Executed Contract” or “Final Draft” only exists as an S3 object tag, Salesforce has no way to surface it in search results. Teams that need rich filtering for high-volume document workflows should ensure their integration maps all relevant attributes into proper Salesforce fields at the time of upload.

What are the compliance and audit risks of metadata gaps in S3-stored files?

Metadata gaps in S3-stored files create genuine compliance and audit exposure. When metadata fields are missing, incomplete, or out of sync between Salesforce and S3, organizations lose the ability to produce a reliable audit trail, demonstrate a document chain of custody, or enforce retention policies consistently. This is a significant risk for industries operating under regulatory requirements around record-keeping.

The most common risk scenarios include:

1. Broken audit trails — if version history is split between Salesforce and S3 without synchronization, auditors cannot reconstruct who changed a document and when
2. Retention policy failures — automated retention rules in Salesforce cannot apply to files it does not fully understand, meaning documents may be kept longer or deleted earlier than policy requires
3. Access control inconsistencies — if permissions are managed in Salesforce but the S3 bucket has separate access settings, a document could be accessible in S3 even after it has been restricted in Salesforce
4. Missing classification data — without consistent metadata tagging, sensitive documents may not be flagged correctly for compliance reviews or data subject requests

Understanding your document value management approach is essential before extending storage to S3, because the metadata architecture decisions made during integration setup have long-term compliance consequences.

How Cartularius helps with Salesforce S3 file metadata management

Cartularius is built specifically to close the metadata gaps that arise when files move between Salesforce and Amazon S3. Rather than leaving metadata synchronization to custom development or manual processes, we handle it as a core part of the platform so your document records stay accurate, searchable, and audit-ready at all times.

Here is what we provide:

• Seamless S3 integration — connect your own S3 bucket and offload file storage without losing metadata fidelity inside Salesforce
• Consistent metadata capture — every file uploaded through Cartularius writes a complete metadata record into Salesforce, including classification fields, version identifiers, and parent record associations
• Version tracking across both systems — we keep version history aligned between Salesforce and S3 so your audit trail is always complete and retrievable
• Cost-efficient scaling — storing files in S3 through Cartularius reduces reliance on expensive Salesforce storage, giving you virtually unlimited capacity at a fraction of the cost in €
• Compliance-ready document workflows — retention rules, access controls, and document classifications are enforced consistently, whether files live in Salesforce or S3

If your team is managing high volumes of documents across Salesforce and S3 and you are concerned about metadata completeness or audit readiness, explore our storage and pricing options to see how Cartularius can bring order to your document environment. Get in touch with us today to start a conversation about what the right setup looks like for your organization.