Trimble e-Builder Embeds Files.com as Its Customer-Facing SFTP Exchange—Without Building a Second Product

Trimble is an industrial technology company whose hardware and software connect the physical and digital worlds for construction and other industries. Its software business includes e-Builder, now sold as Trimble Unity Construct, a construction program management platform for capital program owners including universities, health systems, and public agencies.

An owner running its capital program on e-Builder keeps the program's record there: contracts, budgets, invoices, vendors. But the owner's money does not live in e-Builder. It lives in the owner's own ERP, behind the owner's own firewall, on the owner's own schedule. So project and financial data had to cross between e-Builder's cloud and each customer's environment, in both directions, every day. That crossing was a file exchange, and e-Builder had to deliver it as a working part of its product.

There was no product to replace here. The alternative was for e-Builder to build and operate its own multi-tenant SFTP infrastructure: servers, key management, per-customer isolation, logging, and continuous reliability, maintained forever, for every institutional client. That is a second product, staffed alongside the real one.

A File Exchange That Carries Its Customers' Money

The files that move through that exchange are not attachments. At MIT's Department of Facilities, which runs more than $350 million in construction every year, the financial transactions behind that program flow through the e-Builder drop on Files.com: procurement out, invoicing out, vendor master data out, all of it collected on the far side by SAP.

“All of our procurement goes through that and gets picked up by SAP. All of our invoicing goes through that and gets picked up. It's kind of a big deal.”

That is what failure costs. A transfer that does not arrive, a delivery that silently overwrites the one before it, or a pickup nobody can confirm is not an IT ticket. It is an owner whose invoices are not moving and whose vendors are waiting. Angelone has been blunt about the tolerance for interruption: the exchange has to work, without delays, because every one of those transactions rides on it.

And e-Builder controlled only one end of it. Each institutional customer connected with its own automated systems and scheduled jobs, on its own key requirements, behind its own security review. Files with identical names landed daily. The traffic ran year round. e-Builder had to deliver a machine-to-machine exchange reliable enough for a customer's finance operation, into environments it did not manage.

The Transfer Platform e-Builder Chose Not to Build

What the exchange had to do was clear before any of it was built. Fence every customer into its own space. Speak the SFTP and FTP their automation already spoke, with public and private key authentication and more than one key per user, because that is what production integrations required. Survive a file arriving every day under the same name. Prove, afterward, that a file was actually collected. And run without interruption.

e-Builder made Files.com that exchange. Files.com was not a tool e-Builder used internally. It was a service e-Builder provided to its customers.

One Home Directory, One Set of Keys, per Institutional Customer

Files.com gave each institution a home directory visible only to its scheduled jobs, while e-Builder uploaded under the same client identifiers. One reusable exchange pattern isolated each institutional customer without new infrastructure per client.

Two Files.com behaviors carried the daily grind. Where a customer's system dropped an identically named file every day, Files.com appended a timestamp on upload, so today's delivery could never destroy yesterday's. And the platform's file history recorded uploads, overwrites, downloads, and pickups, so when a customer asked whether a named user or IP actually collected a file, e-Builder answered from the log.

More Than Eight Years on a Single Integration

By mid-2024, the MIT integration had run for more than eight years. A daily delivery could not overwrite the one before it, so a whole class of silent data loss was off the table. Whether a file was collected became a lookup, down to the user and the IP, not an investigation.

The immediate result is an exchange the most demanding customers accept and keep using. The compounding one is that every institutional customer since has cost e-Builder configuration, not construction.

File Exchange as a Product Feature, Not a Second Product

Today, e-Builder's customers connect to e-Builder. What they see is a directory that belongs to them, keys their automation holds, and files that arrive and get picked up on schedule, year after year. What they do not see is a file transfer platform that e-Builder built, because there isn't one. Files.com is the exchange, embedded in the product, and e-Builder's engineers build construction software instead of operating SFTP infrastructure.