Trinity Property Consultants Bridges ADP Email to Vendor SFTP Without Running a Server

Trinity Property Consultants is a property management company with about 1,300 employees across the United States. Trinity runs its technology entirely in the cloud, with no on-premises servers. Every system the company depends on, from property operations to HR, is delivered as a service.

That architecture keeps Trinity out of the business of patching and maintaining machines. It also means Trinity has nowhere to run software of its own. That became a problem the day a vendor demanded a protocol that normally lives on a server.

A Vendor That Only Accepts SFTP and an HR System That Only Sends Email

Trinity brought on a cloud-based provider to produce its employee manuals. The integration required a copy of Trinity's employee list from ADP, its HR system of record, delivered on an ongoing basis so the provider always held the current roster.

The provider accepted the file exactly one way: over SFTP. ADP could send the list exactly one way: as an email attachment. The two systems had no protocol in common, and Trinity controlled neither endpoint. Bridging the gap meant a person manually coordinating every recurring transfer between the two vendors, with no infrastructure anywhere in Trinity's estate on which to automate it.

“Since we don't have servers, we can't do SFTP.”

The Fix Could Not Be a Server

The conventional answer to an SFTP requirement is a machine: something to receive the export, hold the file, and push it out on a schedule. For Trinity that answer got the trade-off backwards. One weekly HR file was not a reason to start owning, patching, and securing infrastructure, and accepting it would have meant a vendor's intake protocol dictating Trinity's architecture.

The requirement was standing, not one-time, so hand-carrying the file was never going to hold either. Whatever bridged the gap had to accept a file the way ADP could send it, deliver it the way the vendor would take it, run on a recurring schedule with nobody in the loop, and exist entirely outside Trinity's estate. Trinity selected Files.com to be that bridge.

An Email Address on One Side, an SFTP Connection on the Other

Trinity's CTO built and tested the workflow himself. The single-workflow rollout required no separate integration project or infrastructure effort.

A Files.com Inbox gave the flow its intake: an email address that accepts inbound messages and extracts their attachments. ADP emails the employee-list CSV to that address on its schedule. The inbox pulls the attachment out of the message and lands it in a folder on Trinity's Files.com site. From there, a scheduled Files.com Automation delivers the file over SFTP to the provider's endpoint every week.

Files.com is the only middleware in the path. There is no agent installed anywhere, because there is nowhere to install one. Both endpoints are someone else's SaaS, and now so is the relay between them.

The Employee List Moves Itself Every Week

With the workflow in production, Trinity replaced manual coordination between two vendors' systems with a relay that runs on its own.

• The current employee list reaches the provider every week with no operator involved. Nobody pulls an attachment out of a mailbox, and nobody pushes a file by hand.
• The vendor's SFTP mandate was met with zero additions to Trinity's infrastructure. No server was stood up, and there is nothing new to patch or maintain.
• The integration runs on the vendor's required protocol without that requirement ever reaching Trinity's architecture. Trinity is still a company with no servers.

The larger result is the pattern. The next system that can only send a file one way, and the next counterparty that will only receive it another, can meet in the same place: a new inbox address and a new delivery rule on the same Files.com site. A protocol mismatch that once posed an infrastructure question is now a configuration task.