Where do the actual files live, in Salesforce or on the external server?

The files stay on the external file server the whole time. Salesforce never stores a duplicate copy. When a user opens a record, Salesforce makes a callout to fetch and render the file on demand, using the record ID and file reference captured at upload time.

Does this approach affect Salesforce storage limits or costs?

That's the point of the pattern. Because files are uploaded straight to the external server through the LWC and only a reference is kept in Salesforce, org file storage consumption stays flat regardless of how many files or how large they are.

Salesforce + Solr Integration Case Study: Federated Search for Email & Files | Tenetizer

Case Study — Salesforce Integration

Bringing Solr-Powered Search Into Salesforce Without Duplicating a Single File

Q: What is a Salesforce External Data Source with the Federated Search type?

It's a Salesforce Setup object that tells Salesforce Search how to query an outside system in real time. Instead of Salesforce holding a copy of the data, the External Data Source sends the user's search terms to a URL you configure, and Salesforce blends the returned results into its own search experience.

Q: Why route email and file search through Solr instead of native Salesforce search?

Salesforce's native search is built for Salesforce records. When the content that needs to be searchable, large file bodies, historical email threads, attachments, lives outside Salesforce, Solr gives full-text indexing, relevance ranking, and query performance at a scale and speed that isn't practical to reproduce with native Salesforce objects.

Q: How does the JWT-based Java middleware work between Salesforce and Solr?

Apex never talks to Solr directly. It calls a Java middleware service, authenticating with a JWT token, and the middleware handles the Solr query or indexing request, translates the response, and returns clean JSON to Salesforce. This keeps Solr's internals off the Salesforce side and centralizes authentication and rate control in one place.

A JWT-secured Java middleware and a Salesforce External Data Source (Federated Search) let users search and open emails and files stored on an external server — directly from the Salesforce record they're already on.

Lightning Web Components Apex Callouts Apache Solr Java Middleware · JWT Auth External Data Source · Federated Search

The Challenge

Records needed to feel complete, without Salesforce holding the content

The client's teams worked inside Salesforce every day, but the files and email history tied to each record lived on a separate content system. Two things had to be true at once: users needed to find and open that content without leaving the record they were on, and Salesforce couldn't become a second copy of a file server that was already doing that job well — for cost, governance, and storage-limit reasons.

That ruled out simply attaching files to Salesforce records. The content needed to stay external and be searchable at Solr-grade speed and relevance, while still feeling native inside the Salesforce UI.

The Solution

Two lanes: a live display path, and an indexed search path

We split the problem into two integrations that share the same external file server but solve different jobs. An upload-and-display lane keeps individual files viewable from the record they belong to, on demand, with zero storage footprint in Salesforce. A separate index-and-search lane feeds file and email content into Solr through a JWT-secured Java middleware, then exposes that Solr index to native Salesforce search through an External Data Source configured for Federated Search.

live, synchronous call indexing / federated query

Technical Flow

How the two lanes actually run

Lane 1 — Upload & Display

What happens the moment a user attaches a file, and every time that record is opened again.

1
User uploads a file from a Lightning Web Component.The LWC sits directly on the record page, so upload happens in context — no separate app or tab.
2
The file, plus its file info and the Salesforce record ID, is sent to the TopMedia server.Salesforce never stores the file body — only enough reference data to look it up again later.
3
When the record loads, Apex makes a callout to TopMedia.The callout uses the stored file reference to request the specific file tied to that record.
4
The file is rendered directly inside the Salesforce record.To the user, it looks and behaves like a native Salesforce attachment — it just isn't stored as one.

Lane 2 — Index & Federated Search

What makes that same content — plus email history — findable from Salesforce search.

1
Emails and files are prepared for indexing.Content sourced from the mailbox and from TopMedia is queued for the Solr index.
2
Apex calls the Java middleware, not Solr directly.Keeping Solr behind a service layer means Salesforce never needs to know Solr's internal API — only the middleware's contract.
3
The middleware authenticates the call with JWT.Every request between Salesforce and the middleware, and between the middleware and Solr, is authenticated with a signed token rather than a static credential.
4
Solr indexes the email and file content.This is what gives search its speed and relevance — full-text indexing designed for exactly this kind of unstructured content.
5
A Salesforce External Data Source, set to type Federated Search, is pointed at the middleware's search endpoint.This is the screen shown above — External Data Source, Name, a Type of FederatedSearch, and the URL and repository parameters that tell Salesforce where to send a search query.
6
Salesforce sends the user's search term out live and blends the results back in.Users get one search experience that spans native Salesforce records and the external Solr index — without Salesforce ever holding a duplicate copy of the underlying content.

Stack

Lightning Web Components Apex (HTTP callouts) Salesforce External Data Sources · Federated Search Apache Solr Java middleware JWT authentication TopMedia file server

Why It's Built This Way

The design decisions that hold the whole thing together

A middleware layer, not a direct Apex-to-Solr call

Putting Java in the middle means Solr's query syntax, connection handling, and scaling live outside Salesforce entirely. Apex only ever talks to one stable, JWT-authenticated contract.

Federated Search instead of data replication

An External Data Source queries Solr at search time. There's no scheduled sync job trying to keep two copies of the same email and file data in agreement — there's only ever one copy.

JWT over static API keys

Tokens are short-lived and scoped, so a compromised credential doesn't hand over standing access — it expires, and the middleware controls who can mint a new one.

File storage stays off Salesforce's books

Because uploads go straight from the LWC to TopMedia, Salesforce's own storage allocation is never touched by file volume — a real cost and governance consideration at scale.

FAQ

Common questions about this integration pattern

What is a Salesforce External Data Source with the Federated Search type?

It's a Setup object that tells Salesforce Search how to query an outside system in real time. Rather than Salesforce holding a copy of the data, the External Data Source sends the user's search term to a URL you configure, and Salesforce blends the returned results into its own search experience.

Why route email and file search through Solr instead of native Salesforce search?

Native Salesforce search is built around Salesforce records. When the searchable content — large file bodies, historical email threads, attachments — actually lives outside Salesforce, Solr gives full-text indexing and relevance ranking at a scale that isn't practical to reproduce natively.

How does the JWT-based Java middleware work between Salesforce and Solr?

Apex never talks to Solr directly. It calls the Java middleware, authenticating with a JWT token; the middleware handles the Solr query or indexing request, translates the response, and hands clean JSON back to Salesforce. Solr's internals stay off the Salesforce side, and authentication is centralized in one place.

Where do the actual files live — Salesforce or the external server?

The files stay on the external server the whole time. Salesforce never stores a duplicate copy; when a user opens a record, Salesforce calls out to fetch and render the file on demand, using the record ID and file reference captured at upload.

Does this affect Salesforce storage limits or costs?

That's the point of the pattern. Because files are uploaded directly to the external server through the LWC and Salesforce keeps only a reference, org file storage consumption stays flat regardless of file volume or size.

Can this Solr + Federated Search pattern be reused for other external systems?

Yes. The External Data Source and JWT middleware layer are generic by design — pointing the same pattern at a different search index or document repository is mostly a configuration change, not a rebuild.

Have Salesforce content trapped outside the platform?

We build Salesforce-native search and display experiences over external systems — Solr, DAM platforms, custom file servers — without moving the data.

Talk to an Architect