A Transportation Visibility Platform Made Email a Front Door to Its Files.com Pipeline

A real-time transportation visibility platform serves major shippers and logistics providers, surfacing live tracking, order, and proof-of-delivery data across road and ocean flows. Its pitch is neutrality: rather than making a shipper's carriers change how they work, the company connects to the systems they already run.

That proposition has a hard edge. A visibility platform is only as complete as its least technical participant, because every counterparty whose data never arrives is a blind spot on a customer's map. And some of the parties the company needs files from cannot run an integration of any kind. What they can do is send an email.

The company brought those email attachments into its existing Files.com and Talend pipeline with Files.com Inboxes and Google Groups, without changing the addresses on its own domain that customers used or giving up internal distribution and email history.

Every Interface but One Ran Through Files.com

The company's file exchange runs on Files.com. Partners and customers get interface accounts and folder structures on the company's own branded Files.com site, where they drop and collect tracking, order, event, and proof-of-delivery files over SFTP, FTP, FTPS, and AS2. On the other side, the company's Talend jobs pull those files out of Files.com and into its order, event, and EDIFACT processing.

Every interface ran through that hub except one. For customers who could only submit files as email attachments, the company used a separate third-party provider to run email-to-folder imports. That was one more vendor to operate for a single narrow channel. It also meant the files from the least technical class of customer arrived on a different vendor's rails, outside the pipeline every other file flowed through. The company had outgrown running a separate system per channel, and the import-by-email interfaces were the last flows outside its hub.

What Replacing the Provider Actually Required

Email as an ingestion channel carried requirements that a naive forward-to-a-folder setup did not meet. Customers had to keep mailing an address on the company's own domain, because the company does not hand its customers a vendor's address or expose the setup behind it. Several internal people needed to receive each message, not just the machine that processed the attachment. And the company needed a complete history of everything a customer had ever sent to the mailbox, retained regardless of what happened to the file downstream.

The replacement had to take email in on the company's own terms and land the attachment in the same folders and the same processing as every other interface. The company moved its legacy import-by-email interfaces onto Files.com inbound email inboxes and retired the third-party provider.

A Google Group in Front of a Files.com Inbox

Each Files.com inbox carried its own email address, and any attachment mailed to that address landed in the folder the inbox pointed at. The company fronted each inbox with a Google Group it already ran. The group held the company-domain address the customer wrote to, and its members were the Files.com inbox address plus the internal people who needed to see the message.

When a customer sent a file, the group fanned the mail out. Colleagues got their copy, and Files.com took the attachment into the same SFTP folder structure a direct upload would land in. From there, nothing about the file was special: Talend pulled it into processing exactly as it did for a file delivered over SFTP or AS2. The Google Group kept the archive, a full history of every mail the customer had sent, held on the company's side and independent of anything that happened after.

The design made email one more protocol into the same folders. Files.com handled the ingestion, and the group in front supplied the branding, the internal fan-out, and the mail history.

One Pipeline for Every Kind of Counterparty

With the inboxes in production, the company replaced a single-purpose import service with a channel inside the platform it already ran.

• Email-only customers now feed the same pipeline as SFTP, FTPS, and AS2 partners: the same folders, the same Talend processing, the same operational picture, with no separate system carrying their files.
• The third-party email-import provider is gone from the estate, along with its operating overhead.
• Customers still mail an address on the company's own domain, and the company still holds a complete history of everything they send. Neither requirement was traded away to consolidate.
• Standing up the next import-by-email interface is a Files.com inbox and a group address. There is no new vendor to engage and no custom path to build.

Email Became a Front Door, Not a Separate System

The company did not build or keep buying an email gateway to serve its least technical counterparties. It made email one more way into the same Files.com folders every other interface is built against, and put its existing distribution lists in front to preserve the branding and the mail history it was never willing to give up.